The problem with the mutability debate is that most examples show two programs, one mutable and one immutable, on the scale of about 20 lines of code. At the small scale, it's a toss-up which is better. Often the mutable solution's more intuitive for most programmers, and sometimes just flat-out superior: more clear, easier to understand. Mutable state isn't evil. It's necessary in the real world. It's just that stateful actions don't compose well, especially when you involve concurrency or Big Code problems. Good programmers learn that they need to
manage (not eliminate) mutable state. That's what FP is about.
So the aesthetic dominance that FP advocates hope to establish with their 20-line A/B depictions doesn't come through, because the truth is that the problems with mutable state very rarely show up (except in contrived, over-complex examples) at 20 LoC. At 20 LoC, the snippet you'll like better is going to be the one you're most familiar with. The real differences show up at 2000 LoC, which can't be put in a PowerPoint.
Immutable programming is somewhat less prone (but not immune) to complexity creep. For example, you see 500-line for-loops in corporate software all the time. The conceptual integrity is gone because so many people (who never learned what the others were doing) have added tweaks to it.
The difference between mutable and immutable programming is that making that sort of change to an immutable program also changes the API, unless it's purely a performance tweak (e.g. plus(2, 2) still returns 4, but does it faster). If you add logging to plus in a purely functional world, you change its signature from (Int, Int) => Int to something like (Int, Int) => (Int, String). As you might guess, that's a double-edged sword. Sometimes you want people to be able to add "purely stateful" (i.e. no API changes) effects without changing a signature... but very rarely.
So I think the major upshot of immutable programming is that it makes it impossible to add many varieties of complexity that corporate engineers tend to add silently (in pursuit of a short-term hack) without changing an API and breaking the build. This slows down complexity creep, and that's a good thing.
It's the reduction of that externalized-cost/complexity-creep dynamic that makes FP superior, in my opinion. A 60-line referentially transparent function really isn't less evil than a 60-line method of an object. They're both fucking incomprehensible, in most cases. You're just less likely to see the 60-liner in a mature FP codebase. Also, because functions compose better than stateful actions, it's usually a lot easier to break large functions up long before they get anywhere near 60 lines. (In my opinion, double-digits are "warning" territory and 25+ lines means it should almost always be split, at least into inner functions.)