Those desiring the change are the ones that need to explain why the change is needed/desirable in the first place.
They have, many times and in different places. If you didn't know that, maybe you should do some research.
I said that the arguments typically presented were weak and unreasonable.
So you do know that arguments and rationale have been made. Ok, how about a substantive counterargument then. Preferably one that actually addresses the arguments given and doesn't just dismiss them as "weak and unreasonable."
The ridiculously common command line that you wrote above fails on many/most distros that have chosen systemd as a default. These systems have no syslog at all.
Every distro that I know of (Red Hat, CentOS, Debian, Ubuntu, Arch) currently installs syslog alongside journald. If you don't have syslog installed, install it, and take it up with your distro for not including it. What your distro decides and decides not to bundle is not the fault of systemd.
Installing syslog on such a system doesn't log systems messages unless you reroute all of them away form systemd/journalctl.
Newsflash: you cannot have two logging daemons listening on the same socket and receiving the same system calls. If you want two logging daemons, one will need to forward that information to the other. JournalD does this, syslog does not, hence the current arrangement where journald forwards logging information to syslog.
But, do carry on insinuating that my log usage or viewing habits are inferior or inadequate because they use the preferred methods of the last 20+ years, rather than your preferred and totally new method. While we're at it, how about the fact that the log file itself is now formatted differently and is binary encoded rather than text. No, that doesn't break anything, 'except old people stuff'.
Wow, defensive much? Whether or not they are inferior or inadequate depends on what you are doing. They are for some people, and journalctl is the solution. If you don't want to use it, that's your choice. Do continue using your method of 20+ years, but you will be missing out on the advantages that journald provides.
As for dependencies, log dependencies are broken, despite your childish refrain of veiled insults. Startup scripts are broken. and the list of broken projects/packages/scripts goes on and on.
If there is a new init system, then old init scripts will be have to rewritten to use it. There is a compatibility method to ease the migration, but a migration will still be necessary eventually. I'm not sure why this is so shocking to you. Your argument basically boils down to "systemd is bad because it isn't sysvinit." If you don't see why that is a ridiculous argument, I don't know what else to say.
These facts aside, you're still arguing with insults.
I am not doing that at all. I am explaining to you how systemd works. You are the one taking it as an insult.
You're not presenting arguments that demonstrate any actual value of the new system/way.
Why do I need to present the arguments in favor of systemd, again, when they have already been made repeatedly elsewhere? At any rate, systemd advocacy is not the purpose of my reply. I am just explaining to you how it works and dispelling the myths that you are perpetuating.
All you've said, like I claimed in the GP, is that my 'unwillingness to accept the new way is because I'm inadequate in my use of Linux and that real users like yourself need all this old shit gone because it's old'.
Nowhere did I say anything like that.
I still say that this is not a valid or logical reason.
It's a good thing that is not one of the reasons then. There is a pretty good summary here (since you insist),