I’ll challenge some of these points, because agreeing doesn’t help us hash out arguments 
IME, there are languages with higher productivity. I’ll call TypeScript as one of those. It does scale maybe a little different: in the beginning, definitely higher productivity. For long-term projects it still scales well, but maybe after a couple of years, Haskell starts to take over.
As such, Haskell’s strength really is long/high maintenance projects. One-off microservices doesn’t seem like a good use case for Haskell, for example.
You can have memory safety without GC. And some applications are made harder due to long-pause GCs. Also see Low-latency garbage collector merged for GHC 8.10 - Well-Typed: The Haskell Consultants
Getting proficient with Haskell performance optimization is a dark art that many Haskellers never learn, because it requires quite deep knowledge about GHC internals. I’d say this is one of the more controversial parts about Haskell.
Yes, but I’d argue that type-level programming is rather unwieldy and there are languages that do this more elegantly. DataKinds, TypeFamilies etc can be confusing and often produce hard to follow code.
It’s not so much “pure functions”, because every language has them. It’s that the language is pure, which is often misunderstood: readFile :: FilePath -> IO String is pure. And is the language being pure really something the developer cares about or more of a nice property for compiler engineers? Because although readFile is pure, I have to reason about it operationally, I can’t reason about it denotationally. That’s all that matters for the programmer, imo, not purity.
Does it? Exception handling, async library, IORefs etc all aren’t particularly trivial and there’s no first-class support for parallelism like in Go. Maybe that’s for the better, I’m not sure.
Is a great source of space leaks: https://www.reddit.com/r/haskell/comments/pvosen/how_can_haskell_programmers_tolerate_space_leaks/?utm_source=share&utm_medium=web2x&context=3
It’s getting better, but in terms of tooling we’re still far behind than most languages.
Often doesn’t play well with type-level programming, e.g. open sum types.
In fact, it is so extensible that we haven’t managed to create a new language report. Good or bad?
This one I can’t agree on. I’ve had terrible bugs in Haskell code that brought down an entire backend or made legal signing of documents impossible due to an amazonka bug.
I think there are only a couple and most haskell companies produce proprietary code and rarely publish any library, let alone allow their employees to work on libraries during their work time.
I hope it stays that way.
Windows often works not so well. Many GHC versions on windows are defunct. cabal and other tools suffer from MAX_PATH issues. Handling of msys2 is hard and confusing. Library support is sometimes sub-par.