Your arguments are all biased and manufactured. That is a frequent observation from me that people who just don't like systemd make up arguments for why it is bad. Quite just like religious people make up argument for why evolution is false. It's also psychology 101 that people form beliefs first and make up arguments later to justify those beliefs. You just don't like systemd. My recommendation is to just give it a try.
"Those you shown are global parameters, not startup scripts."
No, those are the start up scripts.
"SystemD generates diagnostic messages"
Yes, those are extra. There are no diagnostic messages in sysvinit at all. So, you complain that systemd gives you extra tools to debug services.
"systemD instructs you to use some crazy command to parse the binary logs"
All files on a computer a binary and you need some program to read it. The journalctl tool is not crazy, it actually behaves just like grep and tail.
"Usually you can't just disable SystemD, and the tendency (IE it WILL happen), sysvinit will be removed."
The better tools will replace the old and worse tools.
"Precisely. Its not opt-in. And when you manually startup scripts, it captures the useful information the program is outputing *at that instance*."
Let me explain again. If you start a service it will capture sysout and syserr, because otherwise those outputs are lost (like in sysvinit). If you start manually via systemctl those are in the logs and you can see them via systemctl status.
"What we have now, are deamons silently failing and requiring an extra command to understand why"
No, you describe the situation with sysvinit. If a daemon is started on startup the sysout and syserr outputs are lost. Systemd logs them. And also, systemd actually shows you that the daemon failed to start, and blocks other daemons that depend on the failed daemon from starting.