If you look at concept_class, you'll see it can only be retired. While you can purge a concept class that hasn't ever been used, once its used, you can only discourage future use by retiring it.
The use of a primary concept class is for backwards compatibility.
Once the API supports multiple classes per concept, then any future code or opportunities to refactor existing code could remove the assumption that concepts have only one class. That would include searching & display screens. So, yes, it would be preferable to show all classes.
It's a fine thought and there are lots of efforts over the past 50 years or more on building ontologies like this (e.g., UMLS). The challenge is that life is never as clean as your diagram. Relationships between classes can be complex. While we could constrain our use case to a simple hierarchy, we would still face two big challenges in the real world: (1) admins with the time and knowledge to properly create & maintain the class hierarchy and (2) the complexity that comes along with the advantages of the hierarchy being understood by people creating & managing concepts within an implementation and programmers consuming the data.
In the end, I think we're better to keep things simple for now – i.e., just try to go from a single concept class per concept to supporting multiple – and relationships between concept classes could be introduced later (perhaps initially through a module... for example, a module that uses a standard ontology resource like UMLS to enhance searches by understanding relationships between concept classes), allowing us to see how valuable they are in real world usage before committing to the complexity.
Great to see you thinking deeply about this, though.