If PID2 is responsible for critical features like eg. cgroups which affects all running processes, including PID1, then it won't make a difference.
cgroups is a kernel feature. It doesn't stop working because whatever process you're using for cgroup management dies. The process comes back, reads the state from /sys/fs/cgroup, and resumes doing whatever kind of management you wanted. If PID2 only manages cgroups, and cgroups' state is maintained in the kernel (which is is) then it doesn't particularly matter if the daemon craters, so long as you can restart it. But absent many requests for cgroup management, it may not actually even need to be long-running.
The only reason that we even need a daemon for cgroup management is that we're making inadequate use of capabilities. When a user (or script) runs a tool which creates cgroups via a mount, they should not need to use any tool for privilege elevation because they should have the right to manipulate one or more cgroups in one or more approved ways — which can consist of a couple of lines in a file which is sourced by init scripts. In systems with init scripts of any complexity, all of which source external files, no changes need appear in them whatsoever.