Embedding and delegating don't deal very well with virtual dispatch afaik. Declaring different implementations for arbitrary sub-classes seems harder and less elegant without inheritance.
But virtual dispatch is trivial to add where you actually need it, a bunch of function pointers in a struct and you're good to go. And once you stop viewing the world through the OOP filter there aren't that many real hierarchies and interfaces left to deal with. The curse of OOP is that it turns problem solving into day dreaming, with expected results.
OOP isn't the solution to every problem. Your proposed replacement to inheritance would would work nicely in some cases. As far as I can tell, it doesn't address the use case of generic classes at all, at least in a type-safe way.
Generics and OOP are orthogonal, one does not depend on the other. So let's say you declare your vtbl struct with a generic parameter, what's the difference?
> But virtual dispatch is trivial to add where you actually need it, a bunch of function pointers in a struct and you're good to go.
Or let the compiler do it for you? It's like saying I shouldn't use first-class closures, because they're also trivial to implement manually where I actually need them.
Sorry, not buying that one. There's nothing in inheritance that makes extending code easier. You either design for extension or not, has nothing to do with OOP.