Actually, you have it backwards. Enterprises care a great deal about long term maintenance and have large codebases. However, they are also very conservative and prefer the tried and tested approach.
Startups don't typically care about maintenance because, for the most part, they are going for a binary win/lose outcome where in a win they have so many resources that 5x higher maintenance costs are ok, and in the lose they close up shop/pivot and throw the code out. And startups are usually more open to taking a chance on new/different tech.
If there were 3-4 large enterprise companies with 200kloc+ Haskell projects in use I feel Haskell could see long term 20-30% uptake in the enterprise. But few enterprises will take the risk of being one of the first.
Same thinking that leads to not using type inference because it's "harder to read".
I would be very surprised if there were not tens of companies with 200kloc+ Haskell codebases. I know that one of them is an enormous enterprise (but the others that I know of are not).
Let's have an honest conversation. Haskell is a great programming language. It might be the best. It is not going to get more than a 20% market share in the programming community. It could get 1 percent, which is about 5 times what it has now (measured in available jobs) and 25 times what it had 5 years ago. It could get 5 percent. It might even get 15 percent.
Much of our industry is based on trend-chasing. This 25-year-old language that happens to be really good, but whose strongest proponents even admit that it will never have a dominant (25+ percent) market share like Java or Javascript or PHP, is not a shoo-in for "next dominant paradigm".
Functional programming may be the next important paradigm and we're seeing the best programmers and the most important work gravitate toward it, but it's never going to be the go-to tool for the business-driven Scrum engineering that seems to dominate the mainstream of software.