Trustworthiness
It provides the means of constructing systems that can be reasoned about, in which the risks of mistakes can be assessed, in which concurrency can be exploited without compromising those properties.
I once sat on a plane with a guy who ran a company that made software to move money around markets, he was really pleased that they could handle up to 60 transactions a second. They would take a money moment (say $5B) split it into 'maximum risk units' and engage in the conversion between the two currencies. Given the nature of the distributed transaction, the way in which the commitment process operated what was *really* important was managing the overall risk of currency fluctuation in the partially completed distributed transactions. His typical employee at the time (this was about 8-10 years ago) was a good PhD in quantum chromodynamics - they had the ability to think about the 'all possible futures' that the code had to handle. (yes I did my FP evangelisation bit)
That company, with today's Haskell, could start from a simple, obviously correct, description of the issues and evolve a solution - knowing that, with equational reasoning, referential transparency and other properties, the transformations were 'safe'. Doesn't mean you don't test - does mean you can do more with your good staff.
I've used some of the techniques that are in the haskell libraries (esp. iteratee's and dsl's) in developing s/w for intrustion detection companies in the past - granted they were not actually running GHC code - but specialised C coming out of a DSL
Neil