> If an interface fails badly enough that other interfaces get renamed to fill the gap, things don't work
I think that's the opposite of what happens, udev and the practice of associating interface names to the MAC address is so that the interface names are stable across boots and don't get shuffled around in the manner you describe without the sysadmin taking action. 00:11:22:33:44:55 is always eth0 regardless of detection and module load order, if you put in a different NIC with a new MAC and want it to take over an address then you may want to edit the configs before hand, or from the console if you have OOB access.
> But if boot speed is not that important to you, but predictability is, then async device detection, parallelizing the boot, etc add complexity and race conditions that cause more harm than the benefit provided.
I think the point of socket activation is that its fundamentally not race condition prone, and where you want explicit dependencies you can set Before and After to group things. Not having dependancies and service detection at all is inherently racy. As stated, boot speed wasn't a particular design goal but something that fell out of the design, and is worth mentioning, because it's not doing unnecessary work to get the same end result. Spawning thousands of instances of cut and grep and awk to parse config files and whatnot is much more expensive than just using a normal system programming language.