Going by Kay's original definition, Java, C# and C++ do not qualify as object-orientated languages. I think we may have to accept that the original term has become somewhat diluted over time.
However I don't think OOP is all about polymorphism, because you can have polymorphism without objects (e.g. Clojure's protocols or Haskell's type classes).
It's not the original term. OOP started with Simula 67 and then split into 2 branches: the Alan Kay brach and the Barbara Liskov branch.
Alan Kay coined OOP for his branch, but the name caught on. So now OOP can refer to any descendent of Simula 67. Even ones he didn't have in mind (C++ is on the Liskov branch).
The thing is: the branches aren't really compatible philosophically. That's a big reason for the amount of confusion that exists.
In Alan Kay land objects are sub-computers that receive messages from other sub-computers. In Barbara Liskov world objects are abstract data with operators and a hidden representation.
But aside from your unusual interpretation of the word "original", I agree with everything you said.
> OOP is about (subtype) polymorphism... Everything else is there to support and make it easier to apply this concept.
But if that were true, why does your typically OOP language handle polymorphism so poorly? If your only goal is subtype polymorphism, why not just have multimethods and type inheritance and be done with it? Why bother with encapsulation? Why only have single-dispatch?
I'm also not saying that you could throw away the rest - thinking in objects has value, having the ability to inherit implementation has value (in certain cases) and so on; so definitely the whole is bigger than the sum of the parts.
The comment I responded to said OOP is a metaphor ... but now you're saying it's like a Ford Focus with a certain type of combustion engine. That's exactly my point - it's easy to overlook what makes it tick.
And you asks questions to which you (probably) know the answer.
Multimethods are sweat, but a bitch to optimize and only useful in certain use-cases - that's why Clojure is backing away from them. Single-dispatch is what you need in 80% of the cases and it can be optimized aggressively ... notice the JVM where most method-calls end up not doing a vtable-lookup (not that you can have a vtable with multimethods).
C++ / Java handle OOP so poorly because these are languages with a static type system that can't blend in with OOP (where method dispatching is done at runtime). But that's what people asked for.
> Multimethods are sweat, but a bitch to optimize and only useful in certain use-cases
I'm curious, why do you think multiple-dispatch is more difficult to optimize than single-dispatch?