Many systems people want to build with computers cannot be easily conceptualised as graphs of largely self-contained objects, interacting through swapping messages. These problems instead revolve around complex data processing, and are more easily conceptualised as data flowing through a network of functions, and into and out of containers.

It is possible to build these systems using OO, by reifying the network of functions and the data into objects. But all you are really doing is reinventing functional programming with a layer of OO cruft on top of it, and it is always going to be easier to build the equivalent system in a language that lets the functions and the data structures be unencumbered.

For programming tasks that actually are best conceptualised as objects, OO works quite well. These usually involve the provisioning of some largely static virtual environment, such as a UI, game world, or inversion of control container. Here, objects are long-lived, genuinely independent, and interact in well-defined ways via actions and events, usually swapping only small pieces of state.

My guess is that the advent of GUIs and sophisticated games in the 80s and 90s pushed programmers to be more interested in this latter type of problem, and this was reflected in the languages that evolved. Then the advent of the internet and machine learning in the 2000s and 2010s revived interest in data processing and data flow, and so language design began to shift back.

I suspect in 100 years, if humans are still doing any programming, all popular languages will be mixed-paradigm, and the question of OO vs functional will simply be a blend decided by needs of the problem at hand, rather than the kind of dogmatic arguments of this era, which will be viewed through a historical lens as rather quaint and silly.