When I first saw SMF break I had absolutely no clue why I couldnt ssh into the machine nor where to start looking. It was when I discovered that sshd startup was dependent on utmp being available which depended on filesystem mounting being successful that I knew for sure that systemd style init was nothing I wanted.
So if SSH still has that dependency but not enforced, and it starts up before utmp is mounted, and you fix the filesystem problem and move on...
As experienced admins, I don't think either of us know what state SSH is actually in at that point, and we shouldn't be guessing. Is it working, but not logging logins? Do you happen to troll all your daemon logs for random errors... provided this condition is even logged in a sensible manner?
As inconvenient as it is (yes, I know), this feature is to prevent us entering unknown state as much as possible.
If I can make an educated guess, the real problem in that scenario was likely
WAAAAAAY too often in Unix-land people gloss over things like this in favor of the simpler olden days when we just ignored these problems. If those services are designed to be up in a certain order, why take it any other way? Should remote login be available with fewer dependencies - YES! What does that have to do with Init enforcing the ones it does have - NOTHING.
Different subject, but related to what I just said... I saw someone above say they don't have to reboot because they can "restart a daemon".
Use "lsof" next time you patch guys, it's just not that simple, and if you have to take services offline anyway, you may as well reboot just so you know things like fstab are actually correct...