Would a rich commitment to hierarchies and classification be an anathema to Logseq culture?

You misread my comment, I said “better UX for queries” not hierarchies and by that I mean just embrance the “database” approach with tags and properties and ask for a better UX to query them, so that you can browse them maybe interactively with “virtual” hierarchies.

For the use cases stated above I see the current Logseq data structure to be enough but missing representation/navigation.

For example [[Parent]] can have properties like

subcategories:: [[Child 1]], [[Child 2]]
another-hierarchy-subcategories:: [[Child A]], [[Child B]]
extends:: [[X]], [[Y]]
extended-by:: [[Z]]
generalizes:: [[W]]
whatever-you-want:: ...

but what is missed is UI/UX to easily browse them, for example a simple way to say “display the complete tree of pages formed by “extends::” property”.

Think this as databases vs file systems: databases are a more general data structure so you could have different “virtual” file system extracted from the same database.