When ported to 'imperative' languages, those factors from the type system help establish invariant given that people don't use all the footguns. Whilst it is sad there are still footguns that can ruin your invariants, getting better types helps you move away from the footguns. Moreover, it is much harder to export purity to different languages than it is to export good type systems.
And really, the good thing that is being taken over is 'make it easier to reason about correctness through invariants'.
Example: it is fine to have internal state in pure functions, as long as that state doesn't break purity. Haskell's State Monad helps you ensure that. If you're doing FP in a multi-paradigm language, however, it's easy to make a mutation hell.
--
I think the problem with FP and OOP are never with the core concepts themselves, but rather the implementations in the form of multiparadigm languages. They make the escape hatches are too convenient and bad engineering is too accessible.
This can be solved in many ways [1][2] and I don't think haskell's approach is the one that can be imported.
[1]: https://www.microsoft.com/en-us/research/wp-content/uploads/...
In a stateful language a complex type system will eliminate errors in some expressions e.g. "Oh, you tried to add a float number to a file handle!". In a pure functional case a complex type system will eliminate composition errors in the whole program e.g. "Oh, you tried to throw an exception in the code which does not expect any exceptions!".
Naturally, type systems capable of typing a whole program tend to be more complex than ones only needed to type a single expression.
If I were to summarize what I think are the most important ideas in the modern functional programming world, I would start with purity and isolation of side-effects (and the mechanisms that have arisen to manage side-effects). However, it seems like most discussion about functional programming centers on type systems and most of what gets imported to other languages is just fancy ways to do iteration. Purity and side-effect isolation, it seems, is seen as a weird curiosity that must be broken in order to write Real Software (TM). It feels like I've slowly watched functional programming get lost in translation the same way object oriented programming was.
I'm sure the past decade or two of hype around FP has done some good to real code bases by exposing new ideas to developers who might never have seen them before, but I worry that in another ten years, I'll open up someone's code and find a nested callback hell where state mutations are impossible to track.