The faster you unlearn OOP, the better for you and your software

Message passing means that objects have their own data and do not have shared access to it. This makes multi-threading and parallelized code very easy to do because you don't have to worry about data changing unexpectedly. Clojure, and other languages, achieve this by making data immutable, which has a similar effect.

As you mentioned, after Alan Kay used the term "object-oriented" to describe Smalltalk, people focused on the objects instead of the messages and created languages designed around the idea of being object-oriented instead of around message passing (I believe Objective-C and Ruby do message passing), thereby missing the benefit. All OOPLs not based on message passing should die.

Also, unlike Java, Smalltalk has no classes. Any existing object can be used as a template to create a new object.

However, when developing a video game, I ran into quite a few OO design conundrums that IMO were the hardest programming problems to solve in my career. I started looking into data driven design, and while I never changed my code to implement it, it looked like it might have been easier for the video game. I do not know for sure. But I do know that getting OO right in the video game I was implementing was daunting. Maybe I was doing it wrong. The one issue we kept running into was how to design it so that the flow of dependencies flowed in one direction. That is to say, classes should not require references to classes that were higher up the food chain, and vice versa. It sucked when you realize that your Bullet class requires a reference to the BattleField class when the BattleField object was not being passed down through all the intermediate objects that separated the two. I would be willing to say that it could have been poor design, or rather not realizing that dependency earlier in the process to deal with it. But many things we did not know till the requirement or change came up. Then it was programming somersaults to deal with it. Eventually we did get better at re-arranging things as things came up, basically we got used to having to change a lot of the design at a drop of a dime.

I do not know if data driven design would have helped, but it did sound like it was worth a shot. I must admit though, I do remember a data driven program i worked on, and it bothered me how much data had to be passed around that was not relevant to the method/class that was using it. And a lot of data got lumped together out of convenience.

The net result is OOP programs tend to be more complex. Not "more complex than equivalent software". More complex. But also more capable, more abstract, easier to extend, at least along foreseen lines, easier to change (although that's mostly a tooling thing I think).

But yes, bigger, more intricate software is more difficult to debug. Also abstractions don't help, because often the problem is that there are edge cases where the abstraction doesn't work. Also debugging with abstractions require you to know and understand what the abstraction does.

Every paradigm can implement any type of program needed, in principle. The point of criticising a paradigm is to argue to what extent that paradigm encourages that bad programming you mention. If OOP naturally frames problems in a way that leads most people to bad solutions for common problems, that's a legitimate criticism.