Note: This platform / forum is not used by any Alfresco Support Team members. This is a community-focused platform, with most active members being either freelancers, employees of Alfresco partners / service providers, users, or some Alfresco community staff / developer evangelist / community-member-turned-Alfresco-developers.
When considering the amount of nodes in the system, having more custom types which can be used to create highly selective queries should generally be considered better for performance than having only very limited numbers. Any kind of branch / level you can reasonably create and use to differentiate nodes in your content model both during creation but also lookup / query, will improve the selectivity of queries, improving both general query times e.g. for TMQ but also allow for more efficient cache re-use in SOLR queries.
There is no limitation at all as to the number of custom type levels / properties per type. I have work with systems where a single aspect defined up to 100 properties, from which only maybe a few dozen would be set on individual nodes.
In contrast to the data model, you should probably be more concerned with your technical server architecture / scaling and optimisation of supporting services, e.g. ensuring your DB can cope with the amount of data (by vertical / horizontal scaling), and prepare to use sharding for SOLR. You may also want to look into adjusting ACS allocated memory and cache configuration to ensure that you have a sufficient part of the hourly/daily working set of nodes cached at runtime, and do not suffer from frequent cache overflows / invalidations, causing ACS to do many repetitive loads from the DB and slowing down on average as a result.