My #1 issue with OO is that it imposes a large cognitive burden 100% of the time you use it, but the benefits it delivers are not useful anywhere near 100% of the time. For every class someone writes and then inherits from or otherwise uses it as something more useful than "a struct with functions in it", there are probably dozens of classes written with pro forma OO-ness that have internals that read not much different from, say, classic Pascal. It is simply that most code people write is "doing things" in the form of transforming or manipulating a piece of data... take data and save to the database, or take input and validate it and then pass it to another function, or take data from the database and push it through a REST API... and only a small portion of code is generic enough for actual reuse or inheritance or whatever to be useful.

The problem is, where inheritance, reuse, etc. do make sense... the nature is that they are highly visible places like standard libraries. There's a reason why the code you write for your company accounting app looks nothing like the standard libraries, because they are code for general use cases and you are implementing business logic.

But this gets lost, and people think they need to be OOP all the time.

It's like microservices! Yes, they have a very important role in some very big companies like AirBnB or Netflix. No, they are not how you should be writing your internal accounting application...

J.Ja