> If it were true, why aren't Haskell developers taking over the world with their superior software?
Haskell doesn't make superior software; it just (as far as I understand) allows you to make software of equivalent quality, faster. (As is true of functional languages generally; and of strongly-typed languages with type inference generally.)
Quality in all software projects sort of approaches perfection asymptotically, because nobody is all that interested in "perfect software." People just put in less and less QA effort as software "stabilizes", so the remaining bugs in a codebase (even one of static size! even bugs equally easy to find!) are found more and more slowly over time.
One could likely take a "military discipline" approach to line-by-line code reviews, and get a constant output of bugs found per man-hour; but nobody except NASA—and possibly the military itself—is ever going to bother.
---
All that being said, when people say "Haskell programmer", they're more-often-than-not referring not to anyone who codes in Haskell, but to the very specific type of person who creates Haskell libraries encoding new category-theory abstractions—which is to say, mathematicians.
Programmers who happen to also be mathematicians do write "better" software than programmers who are not mathematicians, I think. This is just because mathematicians have much broader mental libraries of abstractions available to them, where any one of those abstractions may be the key to reducing an ugly, complex solution to a simple and elegant one.
Being a mathematician doesn't force you to code in any particular language, but a lot of them happen to be drawn to Haskell when testing out constructions of new abstractions in category theory, computability theory, information theory, etc. Other Haskell programmers can then take these abstractions and—if they can understand them—reuse them in regular programs, such that those programs then become more elegant, in the same way they would be if a mathematician wrote them themselves.
Of course, just because these libraries happen to be brought into existence in the Haskell ecosystem, is no reason for them to stay there. You can port such abstractions to any language you like (if it can support them—but many languages do!)
It's just not often done, because it is kind of hard to "see the point" in such abstractions without reading this-or-that paper... and all the people who are willing to do that gravitate toward Haskell, leaving the rest of the language ecosystem with very few people interested in expanding their language-of-choice's abstraction capabilities. (Another sad network effect.)