I think I get the idea but I don’t really think this is a well posed question. First, having a lot of properties is not orthogonal to have a lot of classes.
I think what you want to know is that if this is always relevant to have explicit class membership with an « instance of » statement, and if it is relevant to have items for specific classes (how deep?).
Indeed, the concept of a « main sequence » star (main sequence (Q3450) ). Conceptually, this maps to a class of star. To retrieve all the stars of this class, we could surely, assuming we have stars with enough informations about their magnitude and color in it, create a SPARQL query that finds all its instances. Note that this query must combine the values of magnitude and on color to compute the set of stars that match.
I’ll explore two solutions :
1 : we assert the « instance of » relationship on the item
2 : we don’t, and we assume the query is enough, and just mark the stars as « instance of : star»
There is probably a third one which could be to create a property « senquence of the star » but imho there is so little pros we should not even think about it. The only thing I could find is that it’s widely used in infoboxes to have such a field.
Pros of 2 : we don’t have to put an explicit «instance of» statement.
Cons of 2 : The class membership won’t be shown on Wikidata page about the star item atm. A star in which we only know that it in main sequence but don’t know the magnitude won’t show up in the query result. Queries have no items atm, so the query does not even exists as far as Wikidata data model knows.
Pros of 1 : We can add a star we could not show up in the query because we miss the magnitude or the color as instance of «main sequence star». We can always put the «instance of » to the most precise class we know and don’t have to stop at an arbitrary level.
In both cases we keep the item main sequence (Q3450) . We probably in both cases have to assert the subclass relationship between the two classes. We keep the properties «magnitude» and «color», so this has no real incidence on the number of properties in the database.
As a conclusion, I think this definitely is a false dilemma. There «is» a strong relationship between properties, queries and classes. It does not make sense to oppose one to another of this three. We just don’t have the technical ways yet to reflect them (and eventually use them) in Wikidata. The right question is for the dev team : how to implement and exploit this relationship in Wikibase. The qeustion is more a WikiProject Reasoning question than an ontological one.