Sure, but you can do all of these things with the resources stored in a section of the binary, like Windows does. You don't need a special file system feature. I have never understood the rationale for this design.
But when you're (basically) one person designing both the filesystem and all the APIs together, and the idea of crossplatform compatibility hasn't really been invented yet, I can see how it looks like something that belongs in the filesystem layer rathr than as a convention above it. I don't know how it works on Windows, but when you say "section" of the binary, that implies the files have some sort of structure? Is it part of the PE format or how does it work? With the resource manager, any file can have resources, which means some file formats can be implemented using very simple OS APIs.
I'm not talking about cross-platform compatibility. It just seemed over-complicated.
Yes, on Windows it is part of the PE file, which is based on UNIX System V's COFF. These files have a list of sections used to distinguish between code, read only static data, read/write static data, optional debugging information, etc. The resources are just another section with the data in a particular format (probably not dissimilar in format to the Mac resource fork) and Windows has APIs to conveniently access the data.
But one thing this can't do is attach resources to arbitrary file formats. Thank you, that's a use case I was unaware of.
