I think it may be a good idea, very badly implemented. Here's how I see the origins of it:

We started out that every "file" was essentially code that ran on bare metal. We eventually progressed to "files" that could be run by various "programs". But we needed a way for the "system" to identify what "program" to use to run it. Remember that the terms "file", "program" and "system" are abstractions to describe various collections of ones and zeros, and their definitions are more for our convenience than for some intrinsic properties of those particular bits.

Anyway, we eventually decide that the 3-letter extension will indicate what program to run. So if you think about it, the naming convention allowed the filename to actually carry information vital to the file. It was in essense another "stream" of data about the file. We also preserve information about the creation, modification and last-access times, and usernames associated with those times. Again, more "streams" of data.

Once you've accepted the concept that a file should have some sort of "attributes" that you would like to associate with the file, you're not too far from deciding that there should be a flexible way of adding arbitrary numbers and amounts of additional data. Thus secondary data streams.

But here's where the implementation went wrong (IMO): All these additoinal attributes should be contained within the file itself, and the particular program you're using to view the file should present this information in a relevant way. Use a hex or similar low-level editor, it's all there in the top (or bottom) of the file. Use a GUI word processor, it's available from a menu somewhere. But an important consideration should be that if the info in the secondary stream is a vital part of the file, it must actually be a part of the file.

[pause for thought]

I suspect Apple engineers would say this is precisely what they've done, and that the problem is that people are trying to use tools that don't properly handle the extended attributes of the file: that native tools do all this transparently. Assuming I'm correct in this guess, my question is: is the secondary stream (or whatever it's called in Mac-speak) capable of handling arbitrary amounts of information, and if so is this reflected in the file size reported for the primary file?

Which sort of begs the question "whats the difference between a directory containing several files of different types and a file containing several different named streams".

Now with MS announcing they are working on "database as a filesystem" at some future point, it seems the rest of the world might be catching up to the idea of file-as-a-db. Am I in the right ballpark to think that MS's stated goals are essentially what Macs have been doing for years?