He's established both things. First, that class hierarchies are bad when they break encapsulation (he calls this the engineering problem with them).
But he also argues that they don't accommodate change well by their nature (he refers to this as the semantic problem):
>> Furthermore, the idea of building software on top of a tree-shaped ontology would be broken even if our knowledge fit neatly into a tree. Ontologies are not used to build the real world, they are used to describe it from observation. As we learn more, we are constantly updating our ontology, sometimes moving everything around.
>> In software, this is incredibly destructive: Moving everything around breaks everything. In the real world, the humble Platypus does not care if we rearrange the ontology, because we didn’t use the ontology to build Australia, just to describe what we found there.
> He's established both things. First, that class hierarchies are bad when they break encapsulation (he calls this the engineering problem with them).
His exact quote was "Class hierarchies create brittle programs that are difficult to modify."
But he has not demonstrated the first part of that except in one specific case. That case may (?) be common, but it not inherent in the problem - class hierarchies do not require breaking encapsulation.
His conclusion is not supported by his argument because his argument applies only the the strawman he created, and not to the general case to which his conclusion refers.
If I may try to split the difference: His argument applies much more when trying to do OO in JavaScript, because it's much harder to avoid using the parent class's data when you don't have private variables.
But that's a universal issue with JavaScript OO in that it provides no direct language support for encapsulation.
Developers have, for the most part, learnt to be disciplined about not accessing "private" fields in JS objects. That they (we) have not learnt to apply that lesson with respect to class hierarchies is evidence for how willingly we throw away good principles when we are working in a "special case".
It is also a lesson in why having language features that force developers into good practices is sometimes a net win, even though we might also rally against them (because we dislike their verbosity and/or hand-holding).
But he also argues that they don't accommodate change well by their nature (he refers to this as the semantic problem):
>> Furthermore, the idea of building software on top of a tree-shaped ontology would be broken even if our knowledge fit neatly into a tree. Ontologies are not used to build the real world, they are used to describe it from observation. As we learn more, we are constantly updating our ontology, sometimes moving everything around.
>> In software, this is incredibly destructive: Moving everything around breaks everything. In the real world, the humble Platypus does not care if we rearrange the ontology, because we didn’t use the ontology to build Australia, just to describe what we found there.