First, because folders are far more performant for accessing child objects. That's mostly an implementation detail, but a big one - there are tremendous optimizations made on the filesystem that are not accessible for something like ZIP. Particularly relevant to bulk searching/listing - the intent in ReiserFS is that ID3, EXIF tags and the like would move into sub-files.
Second (and this is more a problem in Windows where the 3-letter extension is more important) the OS needs to know which tools it can associate with which type. If a file is a .zip, then it's a .zip and it can use zip tools. If it's not a .zip, it can use the file's own tools (like if it's some kind of music archive). But not both.
the intent in ReiserFS is that ID3, EXIF tags and the like would move into sub-files.
The problem with this is the concept of "files with subfiles" is not a thing outside of ReiserFS. Sure, if people used ReiserFS, they'd have this feature, but how would you transport such files between machines? You'd have to serialize them somehow: this is exactly what ZIP is.
(Remember HFS resource forks? Me neither. They suffered from exactly the same issue: ambiguous transport semantics.)
Optimizations around such things are exactly that – optimizations – and should not affect the semantics of the objects involved. The proper way to approach this is to decouple data storage from indexing from file semantics. Hence a better approach would be to permit access to contents of ZIPs using FUSE (on Linux) or what-have-you, and index the contents in a database like Spotlight (on OS X).
If a file is a .zip, then it's a .zip and it can use zip tools. If it's not a .zip, it can use the file's own tools (like if it's some kind of music archive). But not both.
Ignoring that OOXML (.docx etc.) already takes this approach (zipped XML files), the problem of allowing multiple different programs to access the same type of file is a minor enhancement to the OS. (I'm pretty sure you already can configure Windows to allow .docx to "Open With..." a ZIP program.) Supporting files-which-are-also-folders requires breaking quite a few more assumptions in OSes.
Second (and this is more a problem in Windows where the 3-letter extension is more important) the OS needs to know which tools it can associate with which type. If a file is a .zip, then it's a .zip and it can use zip tools. If it's not a .zip, it can use the file's own tools (like if it's some kind of music archive). But not both.