Bricking systems using rm

Certainly efivarfs doesn't itself manage the way its data is stored, because on some UEFI implementations it runs into the problem where storage allocated for deleted items is only released when the firmware performs a garbage collection cycle at boot[-1]. Writing into it may also provoke system-crashing UEFI bugs when the allocated space becomes full, which cannot be determined ahead-of-time or ensured against, both for the reason mentioned.

In this way efivarfs is an interface shim more than a traditional filesystem, or even a RAM disk. A simple CRUD interface would've likely been more appropriate, with semantics specified according to the minimum of what firmware is known to implement; instead, both users and applications that end up using efivarfs (for whatever purpose) must be aware of these potential quirks, and vendors must test their efivarfs-based features against hardware they're delivered on[0]. This abrogates most of the responsibilities of the operating system as an abstraction layer between userspace programs, hardware, and firmware.

For an ugly word, it's a clusterfuck.

[-1] instead of when the last reference to an open file goes away, as per POSIX semantics
[0] and I can't even begin to imagine the state space involved in such testing, so most likely such tests are run against the freshly-bought configuration and nothing else