Haskell started as a research language by academics, for academics. Business concerns have not been a large concern in its language evolution. That's fine IMO, it's good to have a place where CS researchers can experiment relatively freely without having Big Corporate Stakeholders demanding absolute backwards compatibility for all time (see Python 2->3 for an example of that).
The best parts of Haskell have slowly been copied by other languages (for example: typeclasses became traits in Rust, list comprehensions are in Python, goroutines look a LOT like Haskell threads, etc), while the experiments that didn't work out as much (lazy I/O for example) just don't get copied.
"It's no good for business" just misses the point of a research language completely IMO. That said, some people want to make it more business-oriented and have been making strides towards that goal. Haskell does not really have a BDFL, so anyone can (try to) move the ecosystem in any direction they wish.
From a business pov, the idea would be to assess whether you're happy with what can be done in userland rather than expect syntactic or semantic changes. I can't think of a company that started doing haskell waiting for future features to be added in the language.
https://discourse.haskell.org/t/new-blog-post-haskell-doomed...
I honestly think this is/was an idiotic move; especially since the alternative reading 'avoid "success-at-all-cost"' is not thaaat much better, like (from the second link):
"An example is I/O. For literally years Haskell had no I/O to speak of; more precisely, I/O was unreasonably difficult. For practical utility that was pretty inconvenient. But we stuck to purity…"
I mean, would you want to rest your business on such an attitude? (Which is a great attitude, also gave monads, explained in the link, and advanced the language while keeping it pure). I am not saying a language/environment has to be business friendly, but if you want businesses to use it, it better be.