This folder is needed to create a one-to-one mapping of file on disk with file in ZIP. The same thing happens when you put a file into FAT32 filesystem, which doesn't have support for HFS+ extended attributes. For example, if not for _MacOS folder, you wouldn't be able to store OS X aliases (not Unix symlinks but aliases) in ZIP, which use extended attributes.
Other solutions are 1) use some other archive format which supports extended attributes (e.g. XAR), 2) create ZIP archives without storing extended attributes, losing the ability to unpack exactly what you packed there.
It doesn't sound like a compromise to me. The metadata is added in a way that is useless to all unzip programs except Finder.
The compromise seems to be that they made a Mac-specific derivative zip format, but in a very non-transparent way: it will work just fine for a long time, and then suddenly it doesn't work.
If you have essential metadata (such as aliases) they will still not make it across to a Windows user, and it won't have "just worked". In that case, you'd been better served by a warning when creating the zip.
It's not useless to other ZIP programs: you can unzip and zip back the directory with other programs and it will work just fine. The reason? They didn't make a derivative format.
Of course OS X aliases won't work on Windows -- there's no such thing as alias on this operating system. Just like Windows won't magically set Unix permissions on files extracted from ZIP archive created in Unix format. OS X specific things will be useless on other OSes.
Other solutions are 1) use some other archive format which supports extended attributes (e.g. XAR), 2) create ZIP archives without storing extended attributes, losing the ability to unpack exactly what you packed there.
Apple chose a compromise.