I mentally categorize these discussions of "true OOP" in the same class as "RESTful" API discussions. Nobody is quite sure what they're even arguing about, so the discussions go around endlessly in circles.
RESTful means only that the thing you send has an envelope with enough metadata about what you're doing that middleware can reason enough about it to do things like caching and routing, and also, critically, the methods ("verbs" if you wish) in the envelope correspond only to things a browser can trivially figure out to do based on HTML. But really, in the end it means HTTP, and HTTP is basically like a filesystem protocol with fewer operations (e.g., no RENAME) on the one hand and more (content encoding conversions) on the other.
The moment you need to compose operations into larger, atomic even, transactions, RESTful becomes a pain and the workaround is to treat it like an RPC protocol. And also, on the browser side, you leave HTML-only land and now need JavaScript to compose those transactions.
However, as you'll see in the responses to this, you're actually completely right: there is no true scotsman.
IMHO the great thing of OOP was usability.
This has happened with pretty much every vague thing in the tech: "OOP", "Agile" (SAFe and friends), "RESTful", "serverless", etc...
Smalltalk inspired Erlang, which is the fully-asynchronous messaging/independent threads of execution part of OO only.
Self did OO without inheritance (composition by prototypes).
> Is everything an object?
If the answer is no, you don't have true OOP in front of you. Otherwise, you might want to dig a little deeper.