The reason I use hierarchical models is because they provide more powerful abstraction than purely associative ontologies. I do use ontologies for defining logical objects in an organization (people, document types, costs, risks, etc) but I don't trust end users to invent their own because unless you have a background in it, they just re-create the same narrow taxonomies they use in spreadsheets.

An example would be how a corporate wiki/confluence and sharepoint sites are basically documentation landfills that support labour intensive ad hoc processes without a lot of intelligence. In contrast, a library of functions, microservices directory, data dictionaries, tool kits and categories of processes are an abstraction layer over those landfill elements that enables clarity and scale.

The skill and intuition to aggregate things into abstractions isn't common, so most people don't rely on it, but when you have it, it's really valuable. A rule I use in building ontologies is that a thing without a type is just a poor design decision that leads to conceptual debt, and a type without a thing is just a thing.