The fact is that you Haskell people only talk about the optimizations that can sometimes open on immutable data in specific circumstances. What you generally ignore is the optimizations that immutable data permanently locks you out of with no recourse.
As with most things programming, immutability should be considered a tool, not a rule.
I'm actually quoting Prof Andrew Appel of Princeton: https://www.cs.princeton.edu/~appel/papers/ssafun.pdf
You seem to think that functional programming and in-place updates are mutually exclusive. This is not the case, e.g. Haskell supports mutation as a tracked and controlled side-effect. It can even give static guarantees that a function is pure even it uses mutation internally. Recent research even suggests that compilers can add the in-place updates for us: https://www.microsoft.com/en-us/research/publication/fp2-ful...
You can say SSA, static guarantees, internal mutability, blah blah blah all you want. When third party, not specifically chosen anecdotes to make FP look good, measurements stack up to the claims, we can have a better conversation.
It’s not looking good though, cause these claims of “actually, Haskell is faster than C because compiler magic” have been going on since well before stable Haskell like 15 years ago, and they’ve been lies for just as long.