[adgjlsfhk1]

This is one of several places. Some others are.

You don't know how much memory an object of a given type takes to instantiate. This makes object allocation slower. This also means that you can't allocate a Vector<T> inline. It has to be a vector of pointers.

You don't know what fields a type has. This makes GC scanning more expensive.

You can't optimize the layout of a type. If you know an object doesn't have subtypes, you can move it's fields around to reduce padding. If you want to be able to look up fields quickly, you need to put all the fields of the supertype first in memory which will increase the size of your objects.

[pjmlp]

You can surely allocate a Vector<T> inline, no need for pointers, just make use of compile time polymorphism instead of runtime one.

On OOP languages with GC, you can reduce GC scanning by having precise GC, and if the languages support value types by making use of structs with method pointers.

With the help of PGO for AOT or the JIT, the compiler can optimize the layout of types for the target architecture.

[kaba0]

You are comparing having a feature vs not having it. To make it fair you have to provide for polymorphism, and at that point most of your points become moot in lower level languages as well. Also, bounded subclassing exists (sealed/final classes) so in theory most/some of the optimizations you mention are possible.

[adgjlsfhk1]

IMO, the best way to do this is to provide multimethods to give you both polymorphism while letting the compiler know how objects are laid out.