> The init process is a critical stage: failure tends to leave you with no access to
> the system to diagnose the failure.
Nowdays not really a problem. If this is a desktop system then just hook up a LiveCD with your choosen distro or an USB stick and go on from the live system. With live system images you have all the tools you need and as far as the system's storageis not damaged you can do whatever you wish. As for servers - well remote lights out, management cards, flash addons, consoles etc. you can do whatever to rescue the system. Or if you cant afford it just use serial console to the bootloader and add a failsafe recovery system partition with an image containing all the needed tools and you are ready to go. Mind that these means were used like long time ago even before systemd happened. ;) If you are thinking about disaster then get ready for it when your systems work.
> Shell scripts and plaintext log files may be primitive, but they have the advantage of being easy
> to read with minimal access and not requiring complex stuff to run
Look above - complex stuff to run is not as complex as you see it. You can easly run even an graphical desktop system to recover your system even if you wish for doing so (most live cds do so). You just need to plan it ahead.
> mainly they just require that basic binaries be available in the path
Systemd does not depend on these tiny binaries. In my opinion it is an advantage. It still needs to get unit information from somewhere (like local filesystem or fleet).
> Until I've got at least a basic system up and running enough to log in and work
This is probably the old or wrong way of doing stuff. Just boot from something else and chroot to the system and then check the problem.
> text-based tools will probably run to decipher binary logfiles
You reall don't need to decipher anything as the log files are not ciphered. You just need to open them with specialised tool (avaiable on your rescue media from which you have booted). You don't quite get why people have problem with binary log files do you? The problem is not about tools for accessing them - the main problem is if they get corrupt they are much harder to recover than plain text files.
> and modify configurations
With systemd you do not need any special binary tool to modify configuration.
> The only change I'd make is to make systemd use syslogd like everything else
But it does.
> SysV init scripts may be clunky and primitive, but they've been around a long time.
So?
> People know how to manage them, and they've had the kinks worked out of them and
> best practices established. systemd doesn't have that.
It does. But I get what you're getting at - writing a startup script yourself. So maybe try writing systemd unit for your need yourself and then compare it to sysv. IMVHO systemd units are easier (as more simple) to write than shell scipts for sysvinit. But YMMV.