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.
