The history of programming is devs frustrated at arbitrary limitations of syntax or modelling and forming new ones, with their own arbitrary limitations of syntax or modelling.
When your only tool is a FOR loop hammer, every set based operation frustratingly looks less like a nail than a screw.
Chicken and egg, perhaps? OOO lives and breathes state, so complexity (defined as an excess of state consideration) seems a natural pairing, yet the overhead and complexity is increased by each in response to the necessity of the other? That is, when complexity of the problem shifts, there is a parallel increase in the complexity of the OOO solution.
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 asked Spector about his 'immersive simulations' comment some years back:
"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.
Its foundation of rational logical thought that can't process basic math? Even a toddler understands 2 is more than 1.