Many gives power to the Liskov Substitution Principle. If there are many (more than one) objects to be used in the same way, then it is imperative that an interface is created for them so that they may be used interchangeably (transparently) by the client.

Many objects of the same interface (“type”) may be used one-at-a-time (by reference) or in groups (containers and loops). We don’t write code that calls A and B and C in the same way because that would be “three” and we don’t believe in 3. We believe in Many. It’s a loop over a list. If we’re treating the objects similarly, we should exalt the similarity by putting them in a loop, rather than stress individuality by coding two statements for making the call.

By the way, don’t confuse Many with “two things with similar structure”. Many refers to “more than one thing with similar usage” in the LSP-compliant sense. It doesn’t demand that you create base classes to capture some essential similarities, only that you create interfaces and loops as required.

In a multi-generational GC, the theory is that some things by nature have short lifespans, and others by nature have long lifespans. Most objects are created and deleted, and a few may make it to the third-generation cache where they’re almost never examined (comparatively) for collection. Many has a similar theory. Objects that occur once are singular things, but once they start to multiply they are expected to multiply more in the future. Not only does the “interfaces & loops” keep the code clean, it recognizes the Many things as an extension point in the code. That’s double-benefit if we listen to our code as it goes from one to many.