Honestly I spent enough time to dig into Haskell to learn it well enough to make an informed criticism of the language. I ended up sticking around.
I understand there's plenty of jargon and terms that are unfamiliar to a lot of folks but they're not unapproachable or complex (usually). People commonly point to weird words like, "Functor," or, "Monad." It seems insurmountable and complex but if you really dig in and learn what they mean it's infuriatingly simple and practical. I hardly even notice when I'm using them but I can see the pattern in software everywhere (or where they leak because they don't use them).
Our job is abstraction. And good abstractions matter. There's a reason most software these days isn't written in machine language or assembly. And there's a reason why it's incredibly difficult to verify, say the security properties, of software systems in assembly; we use higher-level languages for that work.
Update: The kind of complexity that is bad in my opinion is the incidental kind that is beyond your control. Move semantics and object initializers are an example of a language abstraction that leaks a lot. It's incredibly hard to write a class that works well in all cases and you have to know a lot about what's happening under the abstraction layer in order to avoid the pitfalls of using them. This kind of complexity is everywhere in software, even Haskell in some places. The blast radius for this kind of complexity has been well managed in Haskell though. So it often comes down to what you need.
In my experience using Haskell has let me spend less time working on errors/bugs (no use after free, off-by-ones, no unhandled cases, I can even avoid a lot of threading and shared state issues) and more time focusing on the problems I"m trying to solve.
