I think perhaps it's more of a "pure OO" approach than the language itself. I've seen plenty of Java and C++ code where there is one interface class for every concrete class, even when just one concrete class is ever implemented, for example. I've also seen cases where some "factory" pattern is force-fit into the architecture, and the objects it creates are kinda sorta related, but ought not be in code. It gets exponentially worse as more interfaces and more levels in a hierarchy are allowed.
The compiler isn't always going to be able to collapse or elide these.
Abstractions yes, expensive, perhaps not. One of the nice things about Java is that the JIT can collapse a lot of abstraction at runtime. Not all of it, but a lot of it. I am skeptical about the idea that Java naturally guides programmers towards expensive abstractions.
> and makes parallelism difficult
Presumably, you mean something like "makes lightweight concurrency difficult, because all the backend APIs for database access etc are blocking", which is unfortunately true.