This strikes me as a sort of ... reverse of survivorship bias.
You look around and see all complex systems are in OO, then you conclude that it is OO that is the cause of the complexity.
Have you considered that the non-OO designs are deficient in some way that prevents them from being used for the type of systems that you find to be examples of OO being bad?
Not that I am defending OO, I just want to know how you are differentiating between "OO produces complex systems" and "OO is used for complex systems".
The general anxiety of the movement towards functional or procedural programming in general might also be a feature of age: a young programmer eager to impress that they can juggle 8 balls effortlessly, but called upon to do the same 15 years later might admit 3 balls sufficed to begin with, and is closer to an attainable sustainable solution.
"I just prefer games that are less puzzle oriented or "single-solution" oriented and games that offer deeper simulations. Simulations allow players to explore not just a space but a "possibility space." They can make their own fun... tell their own stories... solve problems the way they want and see the consequences of their choices."
Maybe precursors to todays sandbox game environments then.
https://www.theatlantic.com/politics/archive/2010/04/why-the...
https://mcdreeamiemusings.com/blog/2019/4/13/gsux1h6bnt8lqjd...
Turns out trying to contain a complex system within a simple system of abstractions is a trendline towards disaster for any enterprise.
(But then, of course, you realize that you've merely shifted the game of haves and have-nots to other kinds of "have" and feel the hubristic urge to socially engineer your way to equal outcomes.)
Compare "blood is thicker than water", which was rooted in the opposite conclusion, that the blood of the covenant is thicker than water of the womb, i.e. your relationships and social bonds outcompete genetic ties.
The failing of meritocracy is that it is tautological; those who succeed did so because they must have been successful. It can't bear scrutiny because, as it turns out, we can have neither fair nor equal grounds for competition (if we're measuring results as comparative, which is the case here), but people secretly desire unfairness as long as there's a chance they will benefit, even if they are not the beneficiary of a given instance or result. See monarchies, lotteries, CEO pay discrepancies, etc... what matters is there was an arbitrary chance you're dealt out at the top.
If it was that easy you wouldn't have a tradition of devs trying for any alternative.
There's obviously a use case for this sort of product, objections appealing to the ease of use of any technical language or toolset are unlikely to be convincing to the majority who are not comfortable with it.
When your only tool is a FOR loop hammer, every set based operation frustratingly looks less like a nail than a screw.