The idea of having several instances is an architecture choice. Instead of having all the users and content served by a single monolith, the users and the content are spread around several instances that then talk to one another in the process called federation to serve that content for other instances.
This spread out architecture allows for lesser hosting costs per instance and if an instance goes down it does not mean the entire service goes down as a whole. You may experience technical difficulties on one instance while the rest are completely fine, just unable to get stuff out of the instance. Additionally, it allows for easier moderation as moderators (admins?) are instance specific. You don’t have to moderate the whole of Lemmy, keeping your own house clean is enough. This means you are likely to have a higher ratio of mods per users with more instances, which leads to better quality in moderation work. Then if some other instance is not behaving, stop federating from them to yours.
And then some. I hope this at least explains some of the design choices at fediverse?
I think you sort of answer your own question when you wonder what the value of having tons of smaller instances versus a smaller number of larger ones as you discuss the stress of federation from the larger instances soon after. Similarly if content is split between multiple instances any single one going down is going to be less noticeable.
As for moderation, everything does not federate everywhere at once, there needs to be some interaction between the instances first (like subscriptions to communities) for things to really start transferring over. Yes, moderation will still take work, but you don’t have to address the entire fediverse at once.
As for
I cannot say I would have explored the effects, so I can’t really comment on the topic. If the delays are significant and there’s straight up things not getting federated, that’d be an issue and should be fixed by the maintainers. Lemmy remains relatively new.