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.

This is not uncommon especially in the Bay Area.

That would be the Big Ball of Mud pattern, in which the old timers are known as swamp guides.

What does the software or company do? For example, do they make software for accountants? Construction?

It's relatively young and the products are all mostly based on what is called data science and machine learning these days.

Then explain web development.

What about it?

Can you give an argument why it's a good model?

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.

You know how well that ended... ;)

... oh, and watch out for Go! ducks

Qwerty did.