That may or may not be true, but presumably you're not suggesting that Haskell is unsuitable for writing software for users whose specs suck, or don't understand their needs?
Here is an excellent example of a design-by-committe specification for a domain that is incoherent, illogical and complex (Part of a modern day building code): http://www.fierabolzano.it/bauschau2005/congress/EN_1995-1-1...
Of course no implementation can be more elegant than the underlying business logic, the question is: how does the language help me write an implementation that is as nice as possible when the business domain is horrible?
I think Haskell code often looks beautiful but I attribute that not only to it being functional/pure/compact/elegant but also to the code usually being examples of "clean" domains (mathematics, etc.) being implemented in a way that is suited for demonstration, and the fact that it is usually written by excellent developers (who are the ones who tend to preach FP, for good reason).
What I'd like to see are some large-ish real world examples of FP architecture for horrible business problems, not nice ones.
I don't know how true that remains for expert Haskell programmers, but I agree that it's the way most introductory to intermediate material comes across.
In academia, you are often looking for the most elegant tool in clean situations.
In industry, you are often looking for the least clumsy tool in messy situations.
Perhaps Haskell is a good choice in one context but a poor choice in the other, at least for those first learning it.