If you look at how probing for hardware works in the Linux kernel, quite a few older drivers (and the occasional feature subtree) have auto-probing disabled by default because it tended to crash some types of hardware. You see this again in lm_sensors, where the auto-probe script specifically asks permission (with a default "no") before it tries certain probes that risk crashing the hardware.
We don't see this as much in recent years as hardware has gotten better - listing the device_ids/vendor_ids on a buss is much safer than poking ISA IO ports - but the problem remains. Some hardware needs special hand-holding, especially in the initial probe or initialize stages. Hence, tools that handle those stages are always going to have special cases and other annoyances.
> the amount of flack being received doesn't seem warranted
The flack against Pottering (and the rest of the systemd cabal) is because this isn't the first time his idealism has caused serious problems for others. Yes, it would be nice if we could just mount UEFI areas (or anything else). In reality, as this bug shows, this is dangerous behavior. It should have been made optional, or the entire idea of exposing those UEFI areas as a filesystem should have been reconsidered - a special purpose tool that handled bugged hardware might have been more appropriate.
Robust systems must work in the real world not just in an ideal one.
Some boards do have something of a "factory reset" in the form of dual bios so that if one is bricked, the backup can still be booted. But it's not a bug that not every motherboard has this feature.
The UNIX philosophy of "everything is a file" has always been based around the conceptual 'contents' of these 'files'. The kernel doesn't (directly) care if you remove a device node (block or character-based), it doesn't care if you remove a pipe, and it doesn't care if you remove a socket - even though all of these things are interfaces to the kernel in one form or another. Removing these files only removes your ability to access that interface.
Simiarly with files in /proc - which, like /sys, is directly exported by the kernel. In many cases the kernel refuses to even allow you to unlink the 'files' in /proc, even when it might make sense. (For example, you can't kill a process by 'rm'ing anything in the relevant /proc directory.) Instead, you update the configuration values that the files in /proc represent by echoing into their contents, where applicable.
The case with the efivars 'file' actually causing the kernel to take action when it's removed is what's at issue here. The fact that it happens to brick some computers is particularly unfortunate, but does a good job with showing the problem here. This isn't what the "everything is a file" philosophy is about.
I think SystemD is in the wrong here. Operating Systems should be protecting users from bricking their hardware.
Harware manufacturers should not be shipping hardware that's nearly impossible to brick, because it results in hardware that is nearly impossible to update.
Quite a few boards have a backup EEPROM to initialize from if the primary EEPROM fails to boot, but who knows if those that do will bother to reinitialize the UEFI variables stored in NVRAM. Honestly, since they are just supposed to be stored in NVRAM what happens if your board battery runs out of juice, will it still brick?
Perhaps systemd could shield users from their motherboard's manufacturer's stupidity, but the amount of flack being received doesn't seem warranted; has the same amount of outrage been directed towards the manufacturers?