No problem, we're discussing about init systems, which systemd is.
The fact PID 1 cannot die is false. It is a process like any other which is subject to segfaults, oom and the likes. You statement that:

Quote:if the service manager dies (which would not happen with PID1) then all the services will become orphan.

is a bit irrelevant, because it COULD die. If it does, you'll have more problems than sshd not running though, but it could. If you service manager is badly written, and thus die, then moving all this logic to PID 1 won't fix the crashes. It will only weaken PID 1.

As for daemons being orphaned, it shouldn't happen if your daemon manager exits correctly (eg, cleanup by killing all children or whatever). If it does though, then yes, you will have orphaned processes. But it is IMO better than a kernel panic!

Regarding the environment, I agree that it should be reset by the service manager before firing up the service. As for the ID of the service manager, they are technically root:root by default (like PID 1), and each service is free to launch themselves as separate users to drop their privileges.

IMO, there is no valid technical reason to keep service management in PID 1. Not even for orphaned processes, as you will adopt them without any context (it could as well be a simple user process, you can treat all of them as daemons).

To get back to the topic, this is one of the first flaws systemd has regarding service management. The internal logic seems to be okay though, but it is not managed at the good level.