No. The file system, is the abstraction. Adding /proc onto it is a use of that abstraction.
There's two basic extreme positions, and you're adopting one, your parent is adopting something closer to the other.
a. The filesystem only exposes filesystems actually on disk, mapped to some hierarchy. As you say, "On the disks the OS manages file systems."
b. The filesystem is (roughly) a hierarchical container of named binary blobs (called "files") with some defined associated metadata, such as permissions.
While you can adopt (a), and that's fine, some of us (myself included) see a lot of value in (b). The biggest problem with only exposing "real" file-storing FSes in the file hierarchy is that it leaves you with a ton of questions about how to expose all the other things. Taking the stance that we're only going to expose "real" files in the file hierarchy leaves us with several classes of objects that aren't files-on-disk, and you need to name them s.t. the user can interact with them. It is certainly possible to expose each different type of thing in a completely separate namespace. You'll probably also need to be able to associate permissions with those objects¹, as so now you've got a named, ACL'd list or hierarchy of objects, and it's starting to look a lot like a filesystem. You now also need another set of tooling to work with each of these classes of objects. You need another set of syscalls for each of these objects.
The great thing about having a unified file hierarchy in the (b) abstraction is that tooling works on all of these different classes of objects different. It's really just the "CRUD" idiom, and normally it allows things to interoperate quite smoothly. I can write a bash script that draws a progress bar of my battery, and it requires no knowledge other than where in the file hierarchy the battery is.
This is, of course, a case where the power is somewhat biting us. That doesn't make the abstraction wrong, nor does it mean the abstraction isn't leaky. (In fact, in this case, the abstraction works really well, I'd say. Any other implementation of UEFI variables is going to have a "delete" call, AFAICT. What bit us here is that all the objects are in one bucket together, and thus rm -rf / removes more than just files.)
> It breaks one of the most fundamental principles that should be followed in man-machine interaction: The principle of least surprise.
While I agree, that doesn't mean we need to throw out all the power of having a unified file system, but it might beget some way of ensuring the user understands what `rm -rf /` actually does. There's certainly more than one way to solve this, some of which don't involve limiting what can be done with the FS. (As some examples: perhaps rm shouldn't recurse to a different FS, and objects of similar types are on different FSs, which prevent the very error that got us here; perhaps some files force "user acknowledgement" of their removal; perhaps it really does get mounted read-only.)
¹While you might be able to get away with "only root accesses UEFI vars" in the scenario that they're not in the file hierarchy, if you remove all non-real-files then you've got a lot of other things to deal with: unix sockets, block devices, terminals, all the various I/O ports, temp sensors, battery data… the list is extensive.