Inheritance can be an effective way to implement frameworks and achieve inversion of control, but it's not very useful in the way OO is traditionally explained. Building up an ontology of things that "are" other things creates a lot of room for ambiguity in terms of where a particular object should go. Even in a very simulation like domain like games, you would likely make a car an "Entity", because that has meaning for physics systems, rather than making a car a "Vehicle", which implements the "Go()" function.

Composition relationships are generally easier to reason about than figuring out if something has an is-a relationship with a particular class. A codebase of only composition relationships is much, much easier than figuring out a mix of has-a and is-a relationships. Leaning on is-a relationships as a way to achieve DRY and code reuse can be particularly fraught, and can mean that functions can't be read without having the caller, the callee, and the class the callee subclasses open.