[Sanddancer]

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

[Uberphallus]

Which is basically doable with folders.

[tjohns]

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.)

[Vendan]

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.