Forgive me, but I'm really new to programming, and I don't really understand why your example is something that shouldn't be used in real programming. Should a Car be a Vehicle object instead of a sub-class?
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.
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.
For example, about 15 years ago I was an idiot and managed to get a job writing some text parsing code. I, of course, used what I just learned in my Comp Sci 101 "Intro to Programming" class and did a fully OO implementation in C++ with iostreams that took nearly a month to write, and never quite worked.
Looking back, the solution was probably implementable in under 10 lines of a scripting language with judicious use of regex.
The point is that people often fall for the first thing they're given, and OO (which incredibly useful when used properly) is an extremely enticing concept that can be very distracting from actually getting a job done.