No. It should at least come up far enough to diagnose and fix. Did you miss the part about not coming up far enough to edit fstab?
Sure, but if that really was the case then it was a bug, most likely a distro bug, or perhaps the OP was impatient and didn't wait 3-5 minutes for daemon timeout.
Well, I had the exact problem: Debian testing, systemd installed without me noting that something big had changed, because, well, when you do a dist-upgrade in testing it is completely normal that many packages are updated (Once upon a time there seems to have been a big warning message about the change of the init system, but not any more). Reboot and there I was looking at an error message that made barely sense, something like "device missing, retrying ...". No information what device, no information how long it will try do retry, and no option to interact beyond "crl-alt-del". Of course I didn't wait three minutes, the machine was running okay three minutes ago.
What I did was reboot into an alternative Linux installation, chroot into de Debian install, switch to openrc because I know it better, and search what the problem might have been. Of course it was a stale entry in /etc/fstab and removing it fixed the problem. Now I'm on systemd, because it was next to impossible to install some high level packages (nothing gnome related, btw) without pulling systemd in.
Normally I wouldn't care about the init system, but with this fstab problem, and later cups failing because I had ipv6 disabled, I'm kind of annoyed. An option that would make systemd issue warnings instead of failing hard, or that gives the option to select from ignore, retry, emergency shell instead of only the latter one (and on top only after a very long timeout) would IMHO be the better solution - at least for the transition when one is upgrading. (For the record: it's not that I'm just complaining here on /., I put the latter opinion also in a related Debian bug report).