Yes, the second-long pause was on the 32bit version, i do not remember noticing this in the 64bit SE version but i only bought that last week and my PC is in transit as i moved places so i haven't had enough time to see how that works. I have an SSD and relatively powerful computer though. In any case, my point is that it doesn't really matter as it doesn't affect anything and you'll notice pauses and performance hiccups way worse than 1ms not only in Skyrim, but in pretty much every high demanding game out there. Especially in open world games (hence the Skyrim reference) where the engines loads and unloads stuff all the time and there isn't a single point where you can have resources "settled". So that 1ms, if it happens rarely enough it wont be noticed by pretty much anyone.

The issue with GCs isn't really that 1ms, the issue is that some GCs (which sadly includes most known ones - like those in Java and C# - but not all GCs) do not provide any form of control beyond mere suggestions. For example last time i checked running System.gc() in Java doesn't really do a full GC run, so you cannot guarantee that by the time gc() returns you'll have all unused memory gone and placing that call between area/level loads in games (where the user expects some sort of delay anyway) doesn't help you much. Similarly you can't just "turn off" the GC until a later point (or until some specified failsafe threshold is reached) so you can't turn off the GC during normal levels and turn it on between level loads and/or when the player opens any inventory/menu/whatever screen (where again a tiny delay will be mostly unnoticed and/or ignored and often can be masked by the UI design) to clean up any garbage.

IMO a GC that gives you such control and takes 100ms is way more useful for games than a GC that give you no control and takes 1ms.