Tony — every time I read that sentiment I think, "The converse is equally likely." Over-thinking (if such a thing is possible) for some, is under-thinking for others. And the Internet shows us everyday that our singularity is indisputable.
As Tony helpfully pointed out, the _virtual structure_ you give your database can be elastic and ephemeral. It is easy to change and delete. It can be hard to recreate, however. One suggestion I have is to create a Collection Set called, for instance, "Collection Sets Trash". Put this in a top-level Collection Set called, for instance, "_MyDatabase Admin Collections", move Collection Sets that you think you will no longer use into it, and once a quarter, or as needed, open it up and delete the actually-never-to-ever-be-used-again Collections.
I have always found it useful to conceive of two separate structures through which I interact with my images database: a _storage_ structure, and a _retrieval_ structure. In Lightroom, the storage structure is identical to and mirrored from the storage structure used by the Finder. (The structure shown by The Finder is also "virtual". It has no direct relationship with where or how the data that makes up your files is stored.) There are useful practices for setting up a storage structure to meet your needs, but they are not what you are asking about, which is your _retrieval structure_. Lightroom separates these two structures by giving each its own Panel in the Left Module Panels of the Library Module. (Note that the contents of the currently selected container(s) in the Left Module Panels of the Library Module will show in the Image Display Area and in the Filmstrip, that the Photos in the Image Display Area {Adobe is sloppy with their nomenclature here} and in the Filmstrip can be filtered, and — important — that this set of possibly filtered Photos is what will be used in any of the other Lightroom Modules. The items in the Left Modules Panels of the Library Module, including Collections and Collection Sets, are semi-permanent sub-sets of all the Photos in the currently-loaded Catalog. The filter in the Image Display Area (and in the Filmstrip) lets you create a ad-hoc sub-sets of these semi-permanent sub-sets.) The "Folders" Panel will show what I suggest you use as your storage structure, and "Collections" Panel will show what I suggest you use as your retrieval structure.
Your question then becomes less one of strategy and more one of intent: what sets of Photos are you going to want to regularly retrieve? I suggest starting by listing these groups of Photos, and organizing them into Collection Sets that make sense to you.
I keep at the top of the Collections Panel in every Catalog I use a Collection Set called "__ThisDatabase Admin" (the prefixed underscores forces it to the top of an alpha-sorted list). There will different Collections here depending on the Catalog, but this is where I keep additional Collection Sets such as "Post-Import Processing" (mostly metadata tasks) and "Global Finders" (Smart Collections such as "Edited today", "Edited in last 24 hours", "Recorded in last week"), and Smart Collections such as "SpecialTempFlag" (via a keyword I use to mark Photos that require attention outside of my normal workflow), "Conflict in Metadata", and anything else that is more about maintaining the database than about processing my work. Below that I have another Collection Set for global Smart Collections that about the Photos and not about administering the database: Picks, Favorites, For Sale — these all depend on your work and your workflow. Below that I keep a Collection Set for Plug-ins' Collections, with a Collection Set for each Plug-in that generates Collections (such as Any Crop, Any Filter, Data Explorer, List View, etc.). Then I have a Collection Set that contains the Smart Collections I use while developing photos recorded during one session (I group by session, and never break that group).
I hope that gives you ideas to work with, from, and against as you build your own retrieval structure.