Haskell programmers generally believe in making it clear what the code means and letting the compiler/runtime figure out the details of how to execute it. A perfect programmer with infinite time could almost certainly get more optimal behaviour by specifying all the details; on the other hand, a language that expects the programmer to specify all the details gives them plenty of opportunity to get those details wrong, or for their choices to become outdated.

In my experience Haskell significantly outperforms C++ on real-world business problems with realistic development effort (as opposed to carefully tuned microbenchmarks). I do think laziness was a mistake (to the point that one of the biggest industrial deployments uses a strict variant instead). I've spent most of my career doing work in Scala that's very much real-world, so as far as I'm concerned all the people talking about these things being academic or overly abstract are talking crap - I use this stuff every day, and whenever I've tried to take a shortcut (e.g. define a slightly law-breaking monad instance, abuse some mutable state somewhere) I've come to regret it later.