It is behind and easy to flick switch called: su or sudo. The claim is that systemd should add a second switch because the first one is "not enough" that the systemd devs disagree with.

There are more operations that root can do that can brick a system or destroy hardware. Why should systemd try even harder to make root not do that?

Because working with su/sudo is still something that's often enough required for normal operations, that IMHO shouldn't have side-effects of that level. The "with great power..." spiel sudo displays is nice, but it isn't just experienced sysadmins running sudo anymore.

Since the OS doesn't provide permission levels to express this difference, it makes sense to create that isolation otherwise.

I've run rm -rf as root in the wrong directory before, and nuked stuff that required a backup to fix. I'd prefer if everything worse than that required some extra mental confirmation that, yes, I'm sure I want to do that.

There is always SELinux which can limit root. It was fairly easy to setup last time I tested it, and there has been attempts in the past to put it in as default.

A lot of distros also alias "rm" to "rm -i", something that many users explicitly disable. Its a complex problem of security vs usability where most discussions has been rehashed several times.

Personally i find rm too accepting, and rm -i too restrictive.

Using rm on its own will happily perform the command without further verification.

On the other hand, rm -i will request a yes/no on every last file involved.

Personally i have taken to using mc for any "complex" file system manipulations.