As a professional Haskell programmer, I wouldn't say Haskell is harder to optimize than C++, I'd say it is different to optimize. Good Haskell programmers start with thinking about high-level concepts and algorithms right, rather than starting with (relatively) low-level, performance-focused good. And when they optimize, the things they're optimizing for are different: space leaks, excessive (and too little) laziness, appropriate data structure sharing (which can be tricky when using laziness to recursively compute a data structure) and so on.
After that, if necessary, they can look at lower-level details (escaping to a high-performance library in another language, skipping things like array bounds check, other low-level tricks, etc.). However, one of the powerful advantages of Haskell is that this sort of low-level, error-prone, ugly code can be isolated behind clean, predictable, functional interfaces. A great example of this is Haskell's ByteString library, where the low-level details are complex enough that I don't necessarily understand all of them, but the external interface is one even a beginning Haskell programmer can effectively and efficiently use.
After that, if necessary, they can look at lower-level details (escaping to a high-performance library in another language, skipping things like array bounds check, other low-level tricks, etc.). However, one of the powerful advantages of Haskell is that this sort of low-level, error-prone, ugly code can be isolated behind clean, predictable, functional interfaces. A great example of this is Haskell's ByteString library, where the low-level details are complex enough that I don't necessarily understand all of them, but the external interface is one even a beginning Haskell programmer can effectively and efficiently use.