There are cases where functional programming is essential, and there are cases where it's an absolute overkill.
Developing the judgment to tell which is which is this 'experience' part. 25 years in this industry and I still undergo frequent regret when I write ugly-but-effective code, and frequent anxiety when I have to write 300 lines to accomplish what can be accomplished in half that.
Time-preference is a blessing and a curse.
Products built in haskell don't seem to have dramatically lower maintenance costs. They don't tend to have features that other products don't have. Nobody buys math.
In all of the recruiter spam I get, the only time that recruiters lead with "what language we use" rather than "what we are building" is when the company is using haskell. This seems backwards and gives a poor impression.
There might be 100 POPL papers that I can use with haskell extensions but ultimately the act of coding is nowhere near the top of the list of important things when building systems to solve problems.
That is your anecdote, mine is the opposite. Using Haskell at my place of work we have lower maintenance costs than other competitors that use Python. We also have features they don't have, such as checked purity (a guarantee that a financial calculation is reproducible) and transparent batching/caching/provenance (made possible by Haskell's expressiveness). None of this would be possible in Python or Java.
Language/notation, is IMHO critical for the ability to think using the right abstractions. To take your argument to the extreme, we should all be still using machine code, because tools don't matter.
There's a lot to be said for a language that is a) important as an idea and b) gets used enough to test out those ideas in practice.
I'd agree with the author that Haskell occupies something of a sweet spot in that regard.