Only for a very limited definition of "almost always". It's almost always superior if you don't hit performance constraints, and if your problem isn't dominated by sequencing, and if your team can handle the functional approach, and if...
Why is it superior? It controls the state space explosion, and therefore makes it easier to understand and reason about your program.
Why could performance be a problem? Think about a functional quicksort algorithm. It doesn't do mutation, so at each stage, it has to return a new sorted list rather than sorting the list in place. As the list gets longer, the performance gets worse compared to an imperative quicksort.
Now, quicksort would actually be implemented as a library, and would be tuned for speed. But the same issue comes up in other ways. If you have to transform data structures, imperative can be more efficient than functional, and the difference grows as the size of the structure increases. (I could have called this area "scaling" instead of "performance".)
When could your problem be dominated by sequencing? It often is in embedded systems, where you're sequencing external hardware to get it to do real-world things. I mean, yes, you could write all that in a monad, but if that's the dominant thing you need to control, what does it gain you?
All that said, making any individual function pure (in the FP sense) is always at least a local win, because that function becomes simpler to understand, debug, and test.