I think the main problem is that people try to shoehorn OOP mechanics into everything, leading to code that is hard to understand.
Not to mention that this is basically encouraged by companies as well, to look "futuristic".
A great example of this approach going horribly wrong is FizzBuzz Enterprise Edition.
OOP can be great to abstract complex concepts into a more human readable format, especially when it comes to states.
But overall it should be used rarely, as it creates a giant code overhead, and only as far as actually needed.
Oh no, the FizzBuzz EE has evolved since I've last viewed it! 😱 Is it bad if it actually reminds me of my current work project's backend (that I haven't written) a bit?
I got as far as seeing they chose Java and opening the constants file, and immediately executed a strategic withdrawal. I love that people went to this level of detail
People (sometimes) use it far too much and in wrong ways.
Like inherit when you could just instantiate, or use a template.
Or when "everything should be a class" was also a bummer (inhetit "run()"), like I'd instantiate "main" twice (cool if it had worked I guess).
Or old code written by "wizards" where they cast cast cast instances onto other classes to use specific behaviour in crazily dangerous manners. And you're the one to "fix it" because it doesn't work well...
Just like any software design principle, it's understood at a surface level by tons of bad developers who then try and solve every problem with that one principle. Then slightly better developers come along and say "ugh this is gross, OOP is bad!" And then they avoid the principle at all costs and tell everyone how bad it is at every opportunity.