Yep, that's exactly what I thought. All the applications which might fail because usr/ is not around are various udev extras, principally usb_db and pci_db. The default rules use these for something to do with Dell Bluetooth devices and to dig vendor descriptions out of the USB/PCI database. In fact, looking at the udev 164 source code, it looks like the stuff derived from the USB/PCI database lands in device properties then is never used for anything...
... ah. I see. PulseAudio uses it, nice example of an unadvertised coupling between programs, that. What does it use it for?
... to populate ZeroConf / Bonjour data, and to set vendor name properties on sources and sinks. Is that *all*? You're emitting a scary warning and triggering flamewars over *that*? Small wonder I never noticed it wasn't working. I hope you're planning to use it for something else in future, or this has really been a tempest in a teapot.
(I note that mapping USB/PCI IDs to vendors is something perfectly doable at runtime, when the system is likely to be up and /usr will be mounted: there's no need to do it at coldplug time. It's not like the USB or PCI databases are root-readable-only or anything like that, and the underlying IDs are stuck in the udev database regardless. However, it might require enhancements to libudev to do that, which is more coupling than the existing 'run usb_id/pci_id' approach.)