That it's possible to write nontrivial programs using immutable data (see Clojure in particular), which makes debugging highly concurrent applications much much easier. That it's possible to achieve precise control over effects with only a moderate amount of overhead. Look at the perennial debate in Ruby-land over whether you should test at the unit or the integration level. In Haskell that's not a choice, it's clear from the very type of a function whether it's a pure function or a function that makes use of context. And when debugging this lets you rule out whole swathes of your program as areas that couldn't possibly be causing the problem (contrast e.g. in Java I've spent days tearing my hair out only to discover that a problem was caused by a bug in a getter method - by convention getters are short and simple and can't possibly go wrong, but there's nothing enforcing that at the compiler level the way there is in Haskell).
Concurrent access of immutable data is super easy since....no real concurrency is going on. But what about when I need concurrency? One can manage the time with which updates are seen (so it is deterministic), but there are many ways to accomplish this beyond one mutable reference to an immutable world style that clojure seems to promote.
I'm sympathetic to that viewpoint; I prefer the Haskell style where some things are mutating and some things are not and you can see which and control when they happen. But I've seen the Clojure style used effectively, building real-world webapps, and I'd take either over the imperative-language style where your tools give you no help and it's up to you to keep track of when mutations can and can't happen.
Here is something I worked on recently. Let's say you could re-parse code while executing it. A lock is needed so you don't modify a statement list while executing it (you don't want execution to see the partial list). This is where you want one mutable reference to the statement list and then change it completely...so you could use an immutable list at this point. But you could just as well create a new mutable list at this point and save some cycles.
