The storage frameworks used for accessing the contents of document bundles treat zip archives as transparent, so a document bundle is still a document bundle if you zip its contents and then give it the name of the original directory.
And the reverse is also true: take, for example, an .epub (which is a zipped hierarchy of HTML files) and unzip its contents into a new directory. Name that directory "foo.epub". iBooks will happily open this "file." And it stores the .epubs you've imported into your iCloud Library this way on disk!
So one day, I'm sitting at customer's office, working on something different, when they come and tell me they have this problem when the application is fed this particular file. I say to one of their devs, show me the file in text editor. They open it, and seeing garbage, say "it's no use". I immediately recognized the ZIP header, so I tell them, unzip it and open the output. Lo and behold, an XML content that let me debug their problem without running the application. Their technical people were impressed by my "wizardy".
(Probably one of the reasons why they later asked my colleague to "encrypt" the file by running some binary transformation on the zipped XML before saving it.)
It's been like that since they switched over to xslx in 2007 or whatever.