The problem lies in that you never have a "Car" which should inherit "Vehicle". It's a question that never comes up in programming. The bad part of it, is that it sometimes makes new programmers look for these kind of concepts in their code, and write class-based code around them. Exactly the problem http://pyvideo.org/video/880/stop-writing-classes discusses.
Basicly it teaches people to think in taxonomies, which is not good for object-oriented programming since it usually results in highly complicated code, with way to many classes and inheritance.
Inheritance is mostly good for factoring out common code between different sub-classes. Or extending library classes in a way that wasn't thought of when they were written.
I don't think I have ever read a programming book that teaches OO in the same way that most developers use it - that is implement top level first and then when you have commonalities between objects abstract them out into parent objects.
Thinking about and mapping out class hierarchies is something that Java enterprise analysts do.
A good example to teach OO would be a config parser. Write a config parsing object, then sub-class for parsing Yaml, INI, XML, etc.
One of the very first things I learned almost immediately after college is that inheritance typically is a bad idea and that composition is a better strategy. With inheritance you have so much thinking overhead with parent to children relationships when most abstractions could easily be viewed as building it through small pieces. Its sad but during my 5 years in UCLA I have not heard the word "composition" once.
Basicly it teaches people to think in taxonomies, which is not good for object-oriented programming since it usually results in highly complicated code, with way to many classes and inheritance.
Inheritance is mostly good for factoring out common code between different sub-classes. Or extending library classes in a way that wasn't thought of when they were written.