I don't know. Given what I know about how cgroups and systemd works, I don't think there's any particular issue with having a thin shim and starting systemd as PID 2, and so getting some of the reliability gains this article talks about. But I don't have all that much knowledge of the details and there may be good technical reasons why that is a bad idea (the man page notes that it is possible via a command line flag, but that it is not supported and only intended for testing). There are some issues surrounding cgroups moving to a single-userspace-arbitrator model, but I don't know what requires this to be PID 1.

The article remarks its pid 1 to catch "bad" services that disown their parents and get defaulted to pid 1.

But I figure if they switched the bulk of systemd to pid 2, any negligent services would get complained about until they were fixed.

This is something systemd can already handle. Linux has APIs to change the 'reaper' process (PR_SET_CHILD_SUBREAPER) so that orphaned processes move to a non PID 1 process.

Almost all daemons have a command line or config file option to skip "daemonizing" so that the parent can watch the PID correctly. For the few that don't, you can fix them, hack them (e.g. LD_PRELOAD wrappers to shutdown their bogus double-forking), seccomp-ptrace them, or simply wrap them with a legacy-style monitor that reads the pid file and forwards signals it receives to the real pid (this last option of course doesn't fix the race conditions inherent in such usage).