The term may be muddied but it’s not meaningless. Alan Kay’s vision of OO (“it’s about message passing”) never seemed to really take off in the world. When people talk about OO they usually mean classes, objects and methods, used for almost everything as the primary unit of composition. And classes with public methods encapsulating private fields. And often with a dash of inheritance. C++ and Java seem like the flag bearers for this style of programming. It’s popular in C# too.
When people criticise OO, they’re usually criticising this the “Effective Java” style, expressed in whatever language. This style is deserving of some criticism - it’s usually more verbose and harder to debug than pure functional code. And it’s usually less performant than the data oriented / data flow programming style you see in most modern game engines.
OOP the paradigm (messaging and memory encapsulation) is pretty different from OOP the style (access modifier, class+method+properties, inheritance).
As a strong proponent of FP the paradigm, I insist OOP the paradigm is great to study and apply in a system software where there are multiple agencies. For example, in a browser there are multiple "agencies", network-facing workers, storage-facing workers, human-facing workers, etc, as each "agencies" runs at different to pace to make its "client" (networkAPI, storageAPI, human) happy, therefore messaging and buffering between those "agencies" inevitable.
FP also suffers the same issue.
FP the paradigm: pure functions, expression-based, recursion, first-class function, parsing > validation (universal, almost applicable in any programming language)
FP the style: monad, functional-based language, tail-call optimization
Being overly-critical over style is not productive in the long term. Someday one will have to leave the tool for a new one.
Learning the universal part of paradigms is useful because it is not dependent to tools.
When people criticise OO, they’re usually criticising this the “Effective Java” style, expressed in whatever language. This style is deserving of some criticism - it’s usually more verbose and harder to debug than pure functional code. And it’s usually less performant than the data oriented / data flow programming style you see in most modern game engines.