People are going to come out of the woodwork to argue about OO specifically, and I'd probably join in, but the higher-level view that I've come to over the years is that one programming paradigm is not the best in all situations. It really helps to work on a lot of different systems that are not all in the same class and look at a lot of code written by people of all skill levels. It's not possible to really talk about all programs, but I will say that the OO way of thinking can very easily be overdone and end up a giant mess. Similarly, the FP way of thinking can also be very easily be overdone and end up a giant mess. The old-style procedural programming (C with a pile of global variables) can easily be overdone and end up a giant mess. Yet all three of those can actually work out great at the right scale on the right problem!
I think the problem is that we can't really architect a program well until after it works and fulfills all of its design requirements. Those are usually in flux and then we have to engineer dimensions of extensibility to prevent committing to the wrong architecture in the beginning. Those extra dimensions of extensibility come at some cost too, as they often mean indirection and cognitive overhead.
We often don't write the same program twice, or even three times, unless it's a really important program or a we just like doing it. Contrast to other fields, e.g. building houses, where we have lots and lots of examples of how to do it and they started to form archetypes. We try to call those design patterns in programming, but they're actually pretty vague and low-level. Can you imagine going to build a house and thinking "yeah, I think I need to use the wood-and-nails design pattern here, and I think I'll do rafters-and-shingles there, with some brick-and-mortar there." Yeah, real specific ideas on how to do it.