I still am not convinced it is a leaky abstraction because of this. Perhaps it is a surprising one, it certainly took me a while to learn about it, I don't think I really appreciated universal file I/O until I worked through a bit of The Linux Programming Interface (recommended!). I see the filesystem now as a standard interface to many parts of the system (including hardware, processes, kernel state, etc) through the kernel. I don't think that /proc/1 is a process, it is an interface to information about a process. It makes sense to me UEFI variables are exposed this way. In fact if anything I'd say the abstraction is not leaky enough here: deleting the files deletes information on firmware, isn't that the promise of a "regular" file? :) Again, I am not defending the current behavior! There's nothing about the abstraction that says such a file must obey to `rm` in this way.

I recently ran into a funny bug, however, that makes me more sympathetic to your point. In Emacs a version of TRAMP mode (which is used to connect to remote servers or to connect locally as a different user) would try to cleanup itself by deleting some sort of tramp history file after a session. And if the history file didn't exist to begin with (or if a setting disabled it, I'm not sure exactly) someone thought it appropriate to simply open up "/dev/null", throwing away all writes to the file -- OK, makes sense so far.

But in TRAMP I often connect as root to my own machine -- it makes it easy to edit files as root, or run a shell in root. And as root you have the power to delete /dev/null! So, TRAMP would delete it without my knowledge... what's odd is that it quickly gets created again (perhaps by Emacs) so that it appears to exist, except that suddenly a) it's a regular file and b) it's owned as root without world write/read permission, so that suddenly all sorts of things start to fail because they can't open /dev/null. Fun.