Mostly the seemingly big initial learning curve; you have to get extensively onboarded in "the Haskell way" (monads are not hard to get but the community is hell-bent on avoiding wording that makes it easier to grok; why?).

That could be okay for many but as I get older, I tend to take people/organizations that require big upfront investment less seriously.

Example: one of the things Elixir has won me over with were its bite-sized introductions and practices. You can be a 3/10 Elixir dev and you can be a 8/10 one, and that's mostly depending on how many of the official tutorials you've covered. The road is mostly a straight line to an acceptable level of proficiency at the end of which you can start choosing to specialize.

Rust, OCaml, Haskell -- they all failed that test for me.

I picked Rust mostly because of the no-GC situation and because of `cargo`. Many older programmers handwave away the importance of good tooling and this is where they lose a lot of potential mind share that can rejuvenate their languages / ecosystems.

Example on this: OCaml's tooling. A lot of people in this ecosystem always degrade the importance of a good task runner + builder + project manager. I spent half a weekend learning `esy` once and mostly tamed it by making it imitate mix/cargo but it wasn't trivial. The end result is a build script that does 80% of what mix/cargo do. The exercise made me scratch my head wondering why what I did back then isn't upstreamed and made official and why is everyone happy to pretend that building an OCaml project is a solved problem when it (very!) clearly isn't.

Haskell's cabal didn't fare better last I tried it -- admittedly that was more than a year ago.

If Haskell has good bite-sized lessons that lead to an actual real job productivity (less academic exercises, please!) then I'd be happy to give it a fair try and maybe make it a part of my toolbox.