Well, some disk interfaces would have ruined any chance of booting in 5s.
SCSI takes so long to start that you can start it asynchronously, but even
then it can't give you userspace (even the initramfs) until SCSI's up. (I
think it takes 10s on my machine with four disks in a rather old
sym53x875: maybe newer controllers are faster?)
More blockdev-related slowdowns that spring to mind: back in the early
2.6.20 days, the MD raid5 and raid6 code was merged. As a result the
system has to do boot-time benchmarking to find the fastest RAID-6 parity
mechanism even if you're only using RAID-5. It seems to me that md could
just start out using any old works-anywhere method, then benchmark and
switch in the background. (It has to be able to switch at runtime anyway,
or it couldn't choose among alternatives at startup like that.)
Using LVM, if you're vgscanning it is of course going to be slower than
not vgscanning: that could be sped up by simply not scanning unless you
know that the hardware has changed, and you could probably determine if
the set of available block devices has changed by digging in sysfs. (Alas
it won't tell you if some complete bastard has pulled the VG, modified it,
and put it back, but in that case the LVM cache files should *still* have
been appropriately updated, so this looks safe to me, at least as long as
the cache files exist. However if I'm wrong we're looking at big disk
corruption...)