Sadly trolls already forced the issue locked but i feel like a sensible thing to do would be to keep that behavior but change the default user for parsing errors from root to nobody.
Systemd is running something as root because it doesn't like something in configuration file, instead of returning error or running it under the correct user. That's a huge WTF and a possible security issue, but alas. Systemd doesn't make mistakes and everything is someone elses fault.
They've had to delete multiple posts from the thread which are nothing but trolls, hell YOUR post is nothing but a troll.
Tempted to label it as a ripple effect of the rising SJW element in FOSS, because both terms seems to attract that group in defense of the shouter without concern for context.
nobody is not a suitable account for running daemons as. It has a very specific purpose, originating in NFS. That purpose is to be the visible owner of files and directories in mounted NFS filesystems in certain circumstances. Daemon processes in general run as unprivileged accounts that should own a minimal amount of filesystem entities relevant to their operation. They certainly should not run as accounts that own vast tracts of the filesystem that the daemon programs have no business dealing in.
* https://askubuntu.com/a/674397/43344
For best results, a daemon process that has dropped privileges should run under the aegis of an unprivileged account that is a rôle account specific to that one service. This allows one to grant filesystem access and object ownership specifically, and enables the kernel's usual mechanisms for preventing other (unprivileged) processes from messing with the daemon process with the likes of ptrace() and kill().
And if the account given as the one to drop privileges to does not exist in the user account database and is invalid, the service should fail to run.
This is what daemontools-family service management does; because setuidgid (or runuid, or chpst, or whatever) abends with a fatal error when it fails to find the account in the system's account database. This is what the Solaris SMF does, too. It switches the service to the "maintenance" state when the "user" property for the method context is wrong:
Nov 12 22:24:17 aocdbs02a inetd[1053]: Property 'user' of instance svc:/network/stdiscover:default is missing, inconsistent or invalid
Nov 12 22:24:17 aocdbs02a inetd[1053]: Invalid configuration for instance svc:/network/stdiscover:default, placing in maintenance