1) systemd is the wrong place for the safety measures. rm is also the wrong place for the safety measures.

2) remounting a mounted FS is a non-trivial operation with lots of corner cases. What happens when another program is accessing that FS at the same time?

It's simple--the kernel needs to be fixed. Access to EFI should require special sequences to cause writes.

systemd folks aren't going to ask for it because Linus will simply piss and moan and close as WONTFIX/NOTABUG.

I believe you hit the nail on the head. Many folk with experience have a different perspective than the folk writing this stuff. Ignoring their perspective dooms you to repeating their mistakes.

The Unix way isnt some holy grail holy shit perfect way. Its the simplest. Simple means its simpler to unfk. Because it will get fk'd.

Rendering someones hardware DOA is a really bad thing. Leaving that as a vector of attack is irresponsible at best.

If Redhat leaves this in expect legal issues.

Honestly, I feel the issue is more rm -rf's default behaviour being to cross filesystems. This is almost always not what you want (and tends to result in deleting network drives, to give an example which has nothing to do with systemd), especially considering attempting to delete a mount point fails.

I think there are at least three issues here.

One is efivarfs making it too easy to destroy stuff. It should probably identify problematic hardware and prohibit modifications that break that hardware. This is no fun, but hardware-specific workarounds are a fact of life for real-world OSes.

One is, as you say, bad default behavior with rm. Crossing filesystems by default is pretty weird. Preventing that unless it's explicitly requested would largely fix this problem and many others too.

And one is mounting efivarfs read-write by default. It's too dangerous to be that easy to modify.

I don't think it's too useful to try to pin one of these down as "the issue." They're all worth fixing.