You are correct that it is easier to use functional languages in some domains. There are quite a few messaging clients that use Erlang under the hood. Facebook uses Haskell for its spam engine, where being very explicit about if a long chain of things fails open or closed is important. These days, most of the major programming languages have ways of representing functional elements.

However, it's hard to make functional programming general purpose. There are some posts about it elsewhere, but iterative programming tends to make reasoning about the storage of different objects in memory quite a bit easier. Given how all abstractions are leaky anyhow, there will almost always eventually be some component that is easier to deal with using OOP. The inverse is not necessarily true.

There are some practical considerations here as well. While it's possible to make OOP-esque structures in functional languages, it's not trivial. Meanwhile, using a piece of functional code in an already OOP system generally isn't too bad - there is, once again, some syntactic sugar, but the scope tends to be clearer. Putting a bit of functional code inside say, a class, tends to muck with the usage and assumptions of said class less than putting a bit of OOP into functional code.