> Ideally, a good compiler that understands FP will, behind the scenes, detect when it's safe to mutate the old data rather than creating a copy. That's a big part of why Haskell manages to be neck-and-neck with C despite being functionally pure.

Not talking against Haskell or FP; The disadvantage is being hard to reason about performance. Ensuring compiler will optimize something will take more cognitive load than simply writing straightforward code.

Imagine having a map() method on an array that produces another array. In a long chained pipeline of such things, compiler may be able to elide extra allocations and generate asm very near to handwritten for loops. But the abstraction breaks when the method does I/O or has side effects - you can't reorder anything in order to elide allocations. (Well this example may not make sense in Haskell because Haskell is lazily evaluated).

However there is a limit to what compiler can do, and it might manifest in edge cases like variation in order of imports. I'd rather have straightforward code than relying on compiler optimizations.

I am not arguing "against abstractions" like some Go fanboys tell you map and filter are less efficient. It is always possible to apply same map filter to iterators/lazy streams instead of arrays and get same performance in straightforward code. But that's not same as keeping in mind what heuristics compiler uses to optimize the code.