Being smart doesn't make you a good engineer, and being a great language or library designer doesn't necessarily make you an authority on language selection for most engineering uses. Finally, take Pike and Cox and their work on Go. Go is a great minimum-change-for-engineers language for Google's purposes. Is it a great language for most? No. But if you're trying to introduce new concepts to thousands of C++ programmers at the same time, Go is a safer bet than trying to go full Haskell.

To further answer your question, "functional programming" isn't always so well-defined. We know, realistically, that pure functional programming isn't going to work for all use cases. Once you're grounded in FP, you think of mutable state (or, in databases, destructive updates and deletes) as an optimization... but sometimes it's an optimization that you need. No language is FP-only because no language can be; even Haskell has the "dirty" IO monad.

I think that most good programmers (like, 99%) recognize the importance of immutability and referential transparency, when possible, and in the function rather than the action being the standard compositional unit for programs. Where there is disagreement is on when, how, and how often to depart from the functional ideal.