In case of a communication gap;
The word 'topology' has a more domain specific meaning in animation and rigging compared to the mathematical one.
It's used to mean that the placement of the lower level components - vertices, edges and faces - are well aligned to the higher level structure of the object, and make up a well defined 2D grid that flows along the models surface. In particular you'd want edges going along/perpendicular to mesh structures such as limbs, and around facial features and other details in a logical manner.
Otherwise when applying deformations as part of an animation the model will not have the detail in the right places to still look good, e.g. if there is no edges perpendicular to a joint in a limb, the bent version of the limb cannot have a clear smooth line along the joint, and the edges and faces become janky.
Under this definition, marching cubes cannot produce good 2D topology, as the mesh features are all aligned to the cardinal grid instead of the features of the object represented.
But there is a technical barrier, which stems from what the 'instancing' actually is on the technical level; uploading only one copy of the geometry to the GPU, and rendering it in multiple places, which you can't do if you want to use separate modifier stack for different copies (since modifiers are done on CPU beforehand). The instancing features are ways to set just that kind of instancing up, and as such fundamentally incompatible with separate modifiers between instances of the same geometry.
But yes, I do see the use case for collection level modifier stacks, I just don't think implementing those is exactly as trivial as you figure it out to be. Not impossible either of course (for example by doing some sort of copy-on-write thing if the geometry is modified), but it'd be introducting a different kind of copying mechanism with significant performance differences, which smells a bit footgunny to me
You're correct in saying there's no real difference between objects and collections, but there is a meaningful distinction between mesh data and objects, in the object just being a container for the mesh. The modifiers, including array, actually work on the underlying mesh data, not the at the object level, and produce a mesh object as an output. As such, the array modifier does not utilize instancing but actually copies the mesh data multiple times in memory (both RAM and GPU memory), which is definitely not what you want with large, complicated scenes.
So it's not actually about the modifiers being able to be used for what you want in one scenario and not being usable in in a slightly different scenario; the array modifier is not really the tool for the job here at all.
The tool to be used for both of the use cases here is instancing, not the modifiers. Setting up your scene with multiple levels of collections and using proper instancing (which the array modifier is not) certainly is possible, there's just a couple of pieces of the puzzle that you seem to be missing (or unobvious hoops you have to know about, depending how you look at the UX).
Instead of arguing about philosophy and good UX design, I hope you don't mind me elaborating in a more step by step way on how to actually set a scene such as your example up.
You can spawn a collection instance at the location an "empty" type object, by selecting "collection" as the instancing type at the instancing section of object properties. You can have many of these empties and position them manually if you were so inclined.
The other thing is that you can use a mesh to spawn instances of an object at each face of the mesh. So you can create a mesh object, and set up instancing to spawn aforementioned "empty" object, that in turn spawns the whole collection, at each face of the mesh. (You do this by parenting the empty to the mesh, and setting instancing type to "Face" in the instancing panel).
This mesh would typically be rather simple, for example just a couple of disjointed faces scattered where you want your collections to spawn. Or just a single face, and mesh modifiers applied to it, such as array. So instead of arraying the collection, we array a mesh consisting of a single face, and each face of the arrayed mesh spawns an empty that spawns the collection, but the end result is the same. (No idea why each face can't be set to spawn the collection directly and we need an intermediate "empty").
You can also set instances to appear from particle systems etc, for example if you want your houses to just be randomly scattered on a surface of an object (like mesh in shape of the city or so)
It's used to mean that the placement of the lower level components - vertices, edges and faces - are well aligned to the higher level structure of the object, and make up a well defined 2D grid that flows along the models surface. In particular you'd want edges going along/perpendicular to mesh structures such as limbs, and around facial features and other details in a logical manner.
Otherwise when applying deformations as part of an animation the model will not have the detail in the right places to still look good, e.g. if there is no edges perpendicular to a joint in a limb, the bent version of the limb cannot have a clear smooth line along the joint, and the edges and faces become janky.
Under this definition, marching cubes cannot produce good 2D topology, as the mesh features are all aligned to the cardinal grid instead of the features of the object represented.