Some of the functional advantages don't really work until fully adopted and supported by language runtime and syntax explicitly. Immutability in particular I consider really an all-or-nothing proposition. Either you can count on the language using value-only-based semantics, or you can't. Any attempt at middle ground will fail when you're someday dealing with a library built on a library built on a library that, whoops, turns out to use the mutable variables your language supports after all, and then the mutability seeps out from there. Or your junior devs come in and spray mutability around 'cause that's what they know and before you're right back in the morass. (One I've grown sensistive to, since it's the one I work professionally in.)
(Also just declaring the semantics of how mutable variables and immutable variables relate in one language turns out to be really tricky problem. Not impossibly tricky; it's been done, after all. But I suspect trying to mix the two in any sort of deep way means that you have unavoidably created a cognitively "large" language.)
If Haskell is going to "win", it'll be on the strength of properties like these, that either you go all in, or you don't get the benefits of them, just the costs. I think instead of 90-10, "90% of the benefits for 10% of the work", it's rather closer to 10-90.