I suppose it's an aside to your main point, but after 15 years of doing this stuff (and learning to code by writing procedural PHP first, back in the 4.0 days),

I suppose it's an aside to your main point, but after 15 years of doing this stuff (and learning to code by writing procedural PHP first, back in the 4.0 days), I've spent a portion of it investing in OOP and now I'm starting to take a step back from it, and I'm having much more fun writing code without having to worry about classifying the code I'm writing. The things that OOP does well can be achieved quite nicely using other programming paradigms: you don't need a class system or a hierarchy to encapsulate your state and behaviours. And a good OOP language gives you the resources to model your behaviours in functional and procedural ways so long as you have first-class functions and good support for expressions in favour of statements. OOP fits much better into an organisational model where you can think about domains, roles, and responsibilities, and all of a sudden your Factories, Validators, Services, Commands, Builders, Entities and Repositories map to the same way of thinking your hierarchy of teams and managers does, with all of the overthinking and bike shedding that comes with it. You could build the same feature without all that but I think you need an experienced and disciplined team to pull it off well. And I think that supports your point: if the entry point to programming wasn't OOP (like with Java or PHP or even Ruby) but something more fundamental, then maybe that gives you the opportunity to decide when you need the power of abstraction that OOP gives you.