This is a harder question than it seems if you want to get across the idea that a type hierarchy should contain variations but with the same interface. If the interface gets extended as you go down the hierarchy then you have the problem that you too-often need to do type casting of variables (Java) or risk runtime failure (Python) if you make certain assignments and then try to message the referenced object.
In particular, I try to get this idea across early, since if it isn't taught and the opposite process is, it can be very hard to unlearn bad (IMO) habits and replace them. It was for me in fact.
It is the same problem you get using too many if-statements and the program becomes so ad-hoc that it is difficult to understand, much less modify.
Your example of cups is pretty good, I think, since cups should all be able to have the same usages (think UI). So, I'd try to think about things in real life that are basically alike, but have variations.
Clothing fits that in some ways. There are many variations on "skirt" or "pants" or "jacket" that all interface to the world in the same way. They have color, closure methods, sizes, etc. but a visit to a clothing store will give you a sense of the variations.
I'll also note that all of the keys on my current keyboard have the same "interface" but all perform a different task.
Smartphones are pretty generic, actually, in spite of the marketing hype. Mine is probably a lot like yours.
Vehicle is a poor choice unless you restrict things greatly. Buses and cars seem to need different interfaces. But, within a narrow range, it might be made to work. If you ask for the "fare" for buses, but not cars then you get in to trouble.
Note that I try to build software, and teach how to build it, so that objects can be responsible for their own actions and when I ask an object to do something it should be able to respond without me knowing (or specifying) its precise implementation.
So, I find problems when the interface and the implementation are too tightly bound together. When I need to do such things. I'd rather extend the interface explicitly (Java, again) and then implement the new interface than simply add public methods to something with a more general interface. Then, (more Java), you can let variables have interface types, rather than concrete types.
FWIW, I can't always accomplish that, but it is a goal and it results in better code.
As I said in a comment to another question, the Linnaeus hierarchy of the animal kingdom consists entirely of abstract "classes" except at the leaves of the structure. I think that is important to keep in mind.