To me, the biggest under-emphasised win for Haskell is fearless refactoring over the long term. (It’s on your list but I’d put it even higher.)
Readers of this thread have much more experience than me, but my impression is that it’s very easy for a dynamically-typed codebase to get to the point where no one dares modify it any more. The original author has left. Two years after that it’s essentially read-only; and it’s only a matter of time before it has to be rewritten from scratch.
In Haskell, it’s possible to do truly major heart-lung-transplant refactors on a 200k-loc code base that is 30 years old. (I know, because I do that to GHC.) That is a major value proposition. Instead of having a 5-year lifetime, your investment has a mult-decade lifetime.
Now, this is somewhat true of any statically-typed language; but the more expressive the type system, the more true it becomes. Haskell is at the bleeding edge of expressiveness, which certainly has its costs, but it has its benefits too.
This is a “total lifetime cost” argument, not a programming productivity one.
I’m an academic, so my opinion on Haskell-in-the-wild is deeply suspect. I’d love to hear from others with concrete of software evolution over its life. For example, am I right to claim that many codebases become essentially un-maintainable after a few years when the original authors have left?
One other thought. You mention concurrency, but you don’t mention STM (software transactional memory). STM is an astonishingly powerful and effective concurrency abstraction. But (after a 10-yera flurrry of interest) no mainstream language has adopted it wholesale because it just doesn’t work well in languages where mutation is the way you get computation done. In contrast, it works brilliantly in Haskell; indeed the “retry” and “orElse” primitives give it qualitatively-new power that I don’t think any imperative-langauge STM implementation ever attempted.
STM has come “in the box” with GHC for around 20 yrs. For concurrent programs, it’s a really big value proposition. (See my 2007 book chapter on “Beautiful concurrency”, getting on for two decades ago.)
Same caveats as above – I’d love to hear from practitioners. Am I over-claiming?