There is a clear ontology in the above classes, and it's nice to formalize that in the language rather than just keep it informal in a naming convention. I mean, why not have subtypes if you have subtypes?
One way of viewing nouns in English is as a hierarchy. At the top of the hierarchy you have "thing", and as you descend the pyramid you get more and more specific. "What is that thing?" -> "What is that animal?" -> "What is that mammal?" -> "What is that ungulate?", etc.
There are times when it is appropriate to use "animal", and times when it is appropriate to use "ungulate". It depends on context. OO allows you to have the same levels of abstraction, and it can be a powerful tool.
NOW, having said that, there are two problems with this:
1) Not everything is a noun. Sometimes you want to deal with verbs.
2) Realistically, these hierarchies (in Java) tend to become overly-complicated over time. That's what OP is talking about.
There are cases, though, like the aforementioned Throwable, where having a deeply (more than 3 layers deep) nested hierarchy is wholly appropriate.
This kind of metaphor is why object systems go so epically wrong. You just want the minimum set of objects that you need to express the problem. In my experience, any attempt to map that to natural language taxonomies leads to a large number of object subtypes that just exist to name things, not DO things.
When dealing with OOP, I stick with patterns and keep everything else as flat as possible.
I think this is an example of an hierarchy without a purpose.
Pointless OO, what's not to love here..