The engineering organization where I work is full of dysfunction. This is because numerous poor practices were ignored or encouraged over the years. Now there is strong inertia against change because the incompetent long-timers know all the tricks and manage their job security through the system as it is.
In your top-level comment you argued it's a bad model and didn't really give an explanation for why. You just make assertions that things are pathological/overly-complex/error-prone in OOP and that other alternatives are better, that it's impossible to reason about memory layout, etc. But I could just as easily assert the opposite is true: that proper OOP does simplify problems down to manageable parts, that encapsulation is what you're supposed to do in proper OOP, that abstracting away memory layout is a good thing, etc... I'm not sure if you find these compelling or not, but if not, then I guess you could see why others feel similarly about your arguments.
IMHO OOP was a part of the big Software Factory model: a relatively simple, quick to understand tool to onboard masses of superficially trained workforce. A few enlightened Architects and Leaders would paint large strokes of class, collaboration, sequence diagrams while hundreds of "coders" would translate these "visions" into shippable artifacts.