FWIW, in my corner of the world (Scala, big data, web services) functional is very much the way things are going. It's a much better fit to the problem domain since all these systems very much look like pipelines. E.g. a web service is a function from request to respone. Big data applications are just applying some function over (possibly streaming) data.
It's happening on the front-end as well, with things like React.
Might be worth remembering that OOP was born out of a need to model the real world (SIMUlation LAnguage). I don't think it's a surprise that functions are a good way to work with mathematical models (that is, after all, how we do math).
For the front end, it's my understanding that event-passing systems are still used quite heavily -- which can also be considered OOP (message passing).
Modelling a car as a sub-class of vehicle etc -- makes most sense when you're modelling real-world objects.
You may be interested in the Actor Model [1] computation style. When used for programming, it looks like a programming paradigm where functional and object-oriented styles are neatly supported and blended without any impedance mismatches. Most code is written in a functional style, but there are abstractions that encapsulate state changes and make it work together with the mostly declarative functions.
There are at least a couple of Coursera lectures teaching this style (one about programming paradigms, the other about reactive programming), it's worth giving it a look.
The actor model isn't a computation style itself so much as a concurrency discipline loosely resembling the style of message-passing OO (a la Smalltalk).
It appears that some people have become so zealously opposed to object orientation that they have been unable to realize that not everything is Java.
It's happening on the front-end as well, with things like React.