If you delete your system efivars, you system doesn't who it is or what it is and is quite frankly is about as useful as a pet rock at that point. There is /nothing/ to reset, the vars are gone.

As to the rest of this thread, bit of some click bait by you and how you're spinning it.

It wasn't just rm -rf / it was rm -rf / --no-preserve-root` ( because most distributions are trying to protect you from yourself, and in order to actually delete root you have to now go the extra mile to tell it to not preserve it ).

This technically has nothing to do with Linux or rm. It has to do with faulty EFI implementations and only with specific motherboard manufacturers. My ASUS boards for instance, don't have this issue, I tried ( I also have a bag of replacement chips on hand just in case ).

As to you getting a notification on your phone that your whole server room is fucked because of this... No. Any competent sysadmin could prevent this from happening quite easily. One suggestion has already been given that would do wonders, mount efivarfs as read-only. In a server that's going to see very little if any boot time let alone grub updates, then it makes no difference for it being read-only. Secondly, and still my favorite, choose a legacy boot. While BIOS may not be the best, it's still (IMO) far better than EFI. Best part is that efivarfs can't be mounted unless you've booted via the EFI option so there's no way to mess with it.

And technically you could go a bit further to protect yourself by requiring rm to use the --one-file-system option meaning it can't delete efivarfs as it's a different file system. This also extends out to your networked drives, so all around a fantastic thing to have on by default.

The only real solution to this is for EFI to have a hard standard for backup variables in case of situations like this where the OS ( any OS could do this, even freebsd booted in EFI mode ) tries to delete the variables. Or simply not allow direct access to the root of efivars and simply have access to them with the ability to write a configuration file and maybe store user defined ones but still leaving the system intact.

This has nothing to do with the OS, but the OS should still make it a pain to attempt such a feat. So as we "fixed" the rm -rf / debacle by adding steps to make it more of a pain, we can do the same for efivarfs.