In general I agree with the sentiment expressed in TFA and generally try to follow it when building new ontologies because asserted subClassOf hierarchies creat

In general I agree with the sentiment expressed in TFA and generally try to follow it when building new ontologies because asserted subClassOf hierarchies create a huge impedance mismatch between how the computer interprets them and what the designer thought they meant (e.g. I've seen people use subClassOf hierarchies to represent a partonomy, but more subtle variants in what "is a" means within a single hierarchy can wreak havoc on usability). It also allows you to defer the deeper modelling until a use case presents itself and build your hierarchies from the underlying structure of the domain (with data) rather than trying to impose an almost surely incorrectly hypothesis about the structure of the domain from the top down (without data). That said, there are a number of cases where hierarchical taxonomies are vital in building information systems. Some examples. A use case where you need a way to guarantee that a space is completely covered without duplicates (important for accounting, or creating menus). Having a single non-overlapping reference space (like a map) is critical for clear communication. A use case where you need to capture some semi hierarchical knowledge from domain experts, e.g. an org chart, or the parts of a car, or the parts of the brain. Org charts are the perfect example of the tradeoff. Consider the US Department of Defense (don't actually do this you will loose your mind). The chain of command is famously a single parent hierarchy, and if it is not, it is a sign that something can go wrong due to conflicting orders. However, let's say I wanted to know which branch of the military funded a certain research project based on the office that wrote the RFP. This question is pretty much impossible to answer for an arbitrary RFP, and the time and effort needed to maintain the full associative ontology and keep it up to date is stupefying huge, AND it is not even clear that such an ontology would actually be pointing to anything that was actually meaningful in the real world (beyond ill defined social and economic relationships between arbitrary groups of primates). Hierarchies are an effective way to collect knowledge from domain experts in a systematic way that does not require them to know that they are writing down a bunch of axioms, but instead can just draw a diagram -- multiple hierarchies are very important here, because hierarchies from different experts usually agree at a high level, and then differ in the details, often due to the use case for the knowledge or from the experimental perspective, not because there is some fundamental ontological difference. In this sense having multiple hierarchies is a way around the problem of ambiguity in the meaning of "is a".