It seems you are knowledgeable on the topic, why not make your criticism a bit more constructive? Why are "multiple data forks/stream" needed and what are they used for? (I don't know very much about file systems)
Basically, the "resource fork" in MacOS was... well, Wikipedia actually puts it pretty well: "a section of a file used to store structured data along with the unstructured data stored within the data fork." It was frequently used to store things like images and icons (and fonts), but could also be used to store metadata. Think of it as the equivalent of having a document database -- a key/value store -- alongside a file.
For a practical example of the metadata, albeit not one from MacOS: BeOS had a similar concept of file attributes as key/value pairs, and some MP3 players would store ID3 tags in files. In a directory window, you could list any custom attributes as columns. When I was a BeOS user, that made it trivially easy to use the file system itself as my answer to iTunes: windows would show artist, album, song title, track number, and playing times (or whatever I wanted), and because you could search on custom attributes and then save those searches as virtual folders, you could easily set up the equivalent of smart playlists.
I never got to use BeOS, and Haiku seems to be stuck perpetually in the "almost there"-stage (Haven't been paying attention in the last couple of years, though). But this helps me understand why people worked and work so doggedly on reviving BeOS.
Howerver, in NTFS at least, attributes/metadata is a pretty flexible database-like storage, yet are not the same thing as alternate streams (a.k.a. resource forks) which are also supported.
"Originally conceived and implemented by programmer Bruce Horn, the resource fork was used for three purposes with Macintosh file system. First, it was used to store all graphical data on disk until it was needed, then retrieved, drawn on the screen, and thrown away. This software variant of virtual memory helped Apple to reduce the memory requirements of the Apple Lisa from 1 MB to 128 KB in the Macintosh. Second, because all the pictures and text were stored separately in a resource fork, it could be used to allow a non-programmer to translate an application for a foreign market, a process called internationalization and localization. And finally, it could be used to distribute nearly all of the components of an application in a single file, reducing clutter and simplifying application installation and removal."
It's essentially a way to gather more information concerning a file/application without needing to fill the overall filesystem with fairly irrelevant data. So it's a natural place for things like the third-party fonts a program needs, the data files that a program uses, the settings a program has, etc. For example, a game could have a save file that's simply named Blah.sav, but in the data streams, it could have Blah.sav:Save1, Blah.sav:Save2, etc
Sure, but if you're browsing the filesystem directly, it looks much cleaner.
Remember that MacOS users spend much more time working directly with the filesystem, because (recent developments with Launchpad aside) there's no analog to Windows' Start Menu. Literally everything is done by navigating directly through your hard drive in Finder. So keeping related files nicely bundled together and tidy is a bigger priority.
(You can also do neat things, like record whether a file was downloaded from the Internet, and from where -- and use that data to display a security warning when a foreign file is first opened. This would be very cumbersome to implement without extended attributes or resource forks.)
so don't go into the app's directory and you don't see the extra files. Keep in mind, the start menu on windows is LITERALLY just a set of folders in your home directory, with a somewhat nice interface on top of them.
