This wasn't removing firmware as in the actual boot code for the motherboard. It was just clearing the list of what drives to attempt to load an OS from. That list is explicitly intended to be accessible to and modifiable by operating systems, to provide a better user experience than the old method of the user having to manually change BIOS settings.

The standard practice for PCs has always been that firmware configuration settings can be cleared (through a jumper or by pulling the battery) to reset the system to its factory state, forcing it to fall back to its conservative and safe defaults. Some systems have apparently forgotten to have defaults. Their firmware is already broken and afflicted with a major bug even if you avoid triggering it in this particular manner.

It shouldn't be possible to brick hardware by running 'rm'.

Right, but it should be possible to brick hardware through firmware updates.

Again, this is the OS's fault.

The EFI variables are just that. Variables not an entire firmware. I think this is where you confusion is. What is happening here is that these variables are presented to the user as a filesystem under /sys. If you run 'rm -rf /' (or even 'rm -rf /sys'), you will start "deleting" these variables (which I assume either sets them to a null-equivalent value, or somehow removes them entirely from wherever they are stored). It sounds like:

  rm /sys/efivar/MyVariable

is roughly equivalent to:

  var obj = {MyVariable: 1};
  obj.MyVariable = null;

or:

  var obj = {MyVariable: 1};
  delete obj.MyVariable;

This bricks the firmware, because some of these variables end up being required. It's on the firmware maker / motherboard manufacturer to make sure that there is a way to recover from this rather than having the firmware fail to startup because some variables are missing.

My understanding is that firmware made to spec would not brick over the the EFI variables getting wiped. The motherboards that are encountering these issues are running firmware that is cutting corners. Unfortunately cutting corners and ignore specs is nothing new for hardware manufacturers who are more concerned with the manufacture of the physical devices and usually put only the minimum amount of effort into getting any sort of software components (firmware, OS device drivers, etc) running.

Why is it the OS's fault if the firmware can't reset itself to factory defaults? You're not modifying the firmware image, you're modifying a scratch area exposed by the firmware for the express purpose of the OS (ab)using it in any way it deems necessary.