"Car extends vehicle" and "duck extends bird" are great examples for the type of lesson they're trying to teach. I'm surprised people have time in their lives to worry about this crap.
edit: Also, what's up with the title for this submission?
If you teach someone that there is value in making Car extend Vehicle just because that expresses a real-world relationship, you are teaching exactly the wrong lesson and your students will create overly complex inheritance hierarchies.
"That's great", thinks the student, "I'll keep that in mind on the offchance I ever need to write code for an automatic carwash..."
Honestly I think these examples are fine as far as they go, but they should be immediately followed up with nontrivial examples demonstrating how you might actually use this in programming problems which don't fall into the category "simulation of real-world objects". Otherwise the student can easily dismiss the whole idea as esoteric.
In my opinion, dickering about this is the equivalent of, "Yeah, those two hortizontal parallel lines are a great symbol for equality as far as it goes, but really students need to understand the difference between equivalence and implication!" It's an equals sign.
Same deal here. It's an analogy. The fact that analogies must be taught properly to be useful is a tautology that doesn't even bear mentioning, yet here we are.
A similar bad example would be using familiar round objects to teach equivalence: there are 10 apples, and 10 oranges, so apples == oranges.
Car's don't extend vehicles, and duck's don't extend birds. Just because we can organize these physical things into conceptual hierarchies based on their functionality, doesn't mean we can use them to understand polymorphism.
As to polymorphism, that comes for free from understanding language. Most people will understand a "No vehicles allowed" sign to prohibit cars but not people. What else is that but an understanding of polymorphism in evaluating a predicate?
Object-orientation works because in some programs, cars can be treated as if they were a vehicle, without knowing what kind of vehicle it is. This is the principle of substitutability, and it's the actual reason that inheritance hierarchies work. But in other programs, cars and other vehicles may not have much in common and should not be part of an inheritance hierarchy!
The real-world ontology is not a reason in and of itself to create an inheritance relationship.
The point is the commonality of mechanism, not the commonality of any specific ontology. And when you're teaching, that's enough for one lesson.
If you said that to students in lesson #1 of an OOP course no one will understand what you're talking about.
Sure maybe the Duck extends Animal example isn't a realistic one, but you've got to give students a chance to get their heads around the very basics first, and they can at least understand it by using simple real-life things.
Only if your students are idiot drones. I think the majority of us went through these same lessons and came out just fine. Stupid is as stupid does (why do I keep saying that so much?) People who are good programmers can take a simplistic lesson like that and grasp the over-all concepts while people destined for terrible careers simply wont. No point bringing down the rest us with them.