OK, I went and learned some things and it turns out I was wrong but (at least assuming Linux, which is fair since this is a thread about systemd) you're wrong too. None of these signals have to be handled by pid 1.
SIGWINCH for a keyboard request is a thing that I did not know about, yes. But this is opt-in functionality for any process that has any VT open and is suitably privileged, and it is simply traditional for init to call ioctl(0, KDSIGACCEPT, SIGWINCH). Any process can request this, not just init; any signal can be used, not just SIGWINCH. And by default, no signal gets sent, neither to init nor to any other process. So init does not need to handle it.
(This of course leaves aside the question of whether anyone uses this functionality. How many users who are not init system developers know about this? And how many people have machines with physical keyboards that are not just running some window system that puts the keyboard in raw mode, anyway?)
See https://github.com/torvalds/linux/blob/v4.7/drivers/tty/vt/k... and L593-602 (initialized to 0 and disabled by default), https://github.com/torvalds/linux/blob/v4.7/drivers/tty/vt/v... (KDSIGACCEPT ioctl allows any suitably privileged process to request this), and http://www.fifi.org/doc/console-tools-dev/examples/spawn_log... (a separate daemon for doing this - via SIGHUP, incidentally - which says, "Note: this functionality has become part of init", implying it was originally not part of init!).
SIGINT on Ctrl-Alt-Del (if reboot(LINUX_REBOOT_CMD_CAD_OFF) has been called), and SIGPWR on power failure from the two drivers that implement it, are sent via the kill_cad_pid() function. This does default to pid 1, but that's just a default. And it's very easy to change that setting in userspace; it's a sysctl, /proc/sys/kernel/cad_pid.
See https://github.com/torvalds/linux/blob/v4.7/init/main.c#L998, which defaults cad_pid to init, and https://github.com/torvalds/linux/blob/v4.7/kernel/sysctl.c#..., the sysctl implementation.
The two drivers that implement SIGPWR, incidentally, are the S390 NMI handler and the SGI SN Platform's system controller driver, both of which I'm pretty sure see no use today. It's usually sent by a userspace process these days, which again could just choose to not use signals.
So none of the signals you've mentioned are pid 1's responsibility, They are traditionally pid 1's responsibility, yes. But those are two very different things, especially if we're talking about using PR_SET_CHILD_SUBREAPER to move all the interesting work out of pid 1.
The remainder of the signals handled by sysvinit, finit, runit, and nosh are all generated by userspace, and minit handles no other signals. And not all of these init systems bother to call KDSIGACCEPT.
I recommend being less condescending, especially if you're going to be wrong. (-: