Almost sounds like early GC is a good idea by that argument because it reduces the total number of checkable objects. ;)
(I understand you're joking, but) As the time garbage collection takes is dependent on the number of object checked, wether they are going to be collected or not, the fastest way to get a complete load sequence with garbage collection is to postpone garbage collection to the very end of the load sequence and not to do it at all before that. This is the only way that you will make sure that every objects is only checked once.
GC can fire during load, many times actually, and that's NORMAL (you load shit, it hits the threshold, GC triggers, the threshold raises, load more shit...). Due to the new GC system we got with, what, WoW 2.0? ... this really shouldn't matter anyway, they're GC steps, not full blown GCs.
What the addon blocks are calls to collectgarbage(). In particular, calls to collectgarbage("collect") are particularly bad, and LibRock (as well as others, like BigWigs) has been known to do one or several of those calls at load time.
The real issue is that the execution of a full garbage collection cycle takes quite some time, because the collector needs to check every objects in the lua virtual machine. The more objects you have, the slower it gets. AddOns, in particular databases-type addons, can have a huge amount of objects, and checking them all is expensive. This cost is only dependant on the number of objects, not on wether they are garbage or not. This is the reason why I partly disagree with people that claims that huge static chunks of data in the VM is okay. It makes a difference for the garbage collector, independant of the fact that you have sufficient hardware memory to contain this data.
The garbage collector in lua 5.1 (and wow, by extension), will work in steps, where, in each step, a given amount of objects will be checked. So, as you insert more objects in the VM, the full collection cycle will require more steps, but each step won't take more time. So, as the VM runs, you add objects (garbage) to the VM by executing code, and these objects will be collected when the subsequent cycle finshes. The more objects you have in the system, the more time it takes for these objects to be collected, and the larger the total number of objects gets. The larger the set of objects, the faster it grows between cycles.
Honestly, the only API that really made any kind of sense, as far as library goes, is "LoadAddOn". Everything else is just fluff and unnecessary.
But somehow the idea that a directory *that has the very specific purpose to separate loadable pieces of code* should be "clean" and "neat" became prevalent. And so Libraries suddenly had to deal with conflicting versions.