As they say, closures are the poor man's objects and vis versa.

That said, most usage of closures in practice tend to have very little state manipulation -- a closure with 5 mutable fields is weird, an object with 5 mutable fields is "clean code" approved. Also, closures have only one entry point which makes making complex ones much more difficult (you have to implement a state machine or dispatch or whatever.)

Standard "design patterns" over-the-top OOP translated to FP would be like passing around collection of closures (one per method) that all alter a big shared mutable state. At that point OOP is definitely going to be faster, but the FP code would be so ugly you wouldn't write it like that to start with.

(As with OO) depends heavily on implementation, but my 2 cents is that functional doesn't apply as much constraints to optimization.

If a compiler is sophisticated enough a functional program should perform as well as a procedural one that uses a comparable garbage collector. But of course real compilers have shortcomings.

I recommend taking a read at Haskell's wiki performance article[1] to have an understanding of the shortcomings that are specific to Haskell.

[1] https://wiki.haskell.org/Performance