If you just want to store arbitrary name-value pairs associated with a file, it seems like you could use any filesystem to do that. Here's an example implementation:

def get(filename, key):
try:
with open(filename + ".ea") as f:
metadata = json.load(f)
except FileNotFoundError:
raise KeyError(key)
return metadata[key]

def set(filename, key, value):
...
# left as an exercise to the reader

A fully robust implementation of the facility requires handling race conditions between concurrent writers, eventual metadata removal when the underlying file is removed, some kind of thinking about how permissions to the file and permissions to the extended attributes relate, and keeping the extended-attribute storage files from cluttering up the usual user interfaces. Still, given how trivial it is to implement the facility if it isn't built into the filesystem, building it into the filesystem seems more like a tradeoff between obvious design alternatives and less like an innovation.

There are lots of ways you can do things like this; Windows 95 started stashing long-filename metadata in the filesystem directory as extra invalid hidden system volume-name read-only filename entries, for example, and 4DOS (and Total Commander) stored timestamps and arbitrarily-long file descriptions in a file in every directory called DESCRIPT.ION.

(With respect to the concurrency and robustness issues, keep in mind that HPFS would regularly lose data if you lost power, disk drives at the time would regularly suffer physical damage if you lost power unless the disk head was parked, common implementations of Pascal at the time would fail to flush buffered I/O data if you failed to close files, PCs mostly weren't multitasking, and users could remove floppy disks from drives at any time without warning, so even a pretty non-robust implementation would have been adequate.)

As for Oberon's filesystem, it wasn't quite the same improvement in directory implementation; in Oberon there is one directory per disk, while in HPFS there is one directory per folder. This may sound like its filesystem was non-hierarchical, but if I recall correctly, it is in fact hierarchical; files are stored under their pathnames in that single directory.

I thought that probably, if Oberon was described so late, its predecessor probably did the same thing, but I just checked out Svend Erik Knudsen's dissertation (ETH No. 7346) on Medos-2 4.2 https://oberoncore.ru/_media/library/knudsen_medos-2_a_modul... and p. 67, at the tail end of §6.2, describes the file name directory of Medos's DiskSystem. There is no mention at all of B-trees. (There is also a "file directory", but it's confusingly named; what it contains is basically inodes.)

It would probably be nice if HPFS had strongly influenced all the filesystems developed after it, but in fact it seems to have had virtually no influence on Sprite-LFS (begun 01990), BSD LFS, ext2fs, FAT32, VFAT, NetApp's WAFL, GFS, HDFS, Ceph, yaffs, or jffs2. I'm sure it had a lot of influence on NTFS. I don't know enough about ZFS, Reiserfs, XFS, HFS+, or exFAT to say; do you? Can you think of any other filesystems that were strongly influenced by HPFS other than NTFS?

Filesystem design seems to be largely a matter of standing on giants' feet.