Faster boot times is obviously nice and clearly it's silly to completely deny we should have faster boot / parallel service start-up, but I do think there's a bit too much emphasis being put on this like it's some sort of holy grail.
If you're scaling hundreds of production nodes, I would hope your system has been designed that you can scale them gradually without actually taking any services offline. As mentioned, a decent server can take 5 -10 minutes to boot. The rc subsystem is a tiny part of this; Literally just the last bit of the FreeBSD boot where the text changes colour. On all of my systems, even a 50% increase in rc performance would probably make about 5% or less difference to overall boot. In any production setting where downtime was a problem, that improvement would be irrelevant.
I don't think shell slows it down that much either. C might make it quicker but again, for me, the majority of the time is spent actually starting the services themselves than the bits of shell glue in-between.
From what I'm aware a lot of the interest behind systems like systemd and launchd in recent years are partly to do without faster start-up, but much more to do with modernising the rc system, improving dependency handling, streamlining all the various process control services (rc/inetd/cron) & allowing services to actually only start when needed rather than on boot. That last one is a big one as it can have a massive impact on battery powered devices, which is a hot topic for operating systems at the moment (not so much in FreeBSD). Also why try and get your services to start faster on boot if you can just start them later when they're actually needed? (Both those last sentences are fairly irrelevant for servers).
One place where it would make a noticeable 'start-up' improvement would be jails/containers, which are pretty popular these days. All a jail really does when it starts is run the rc subsystem, so a 25% speed improvement would make the jail start nearly 25% faster.
