1. Because a DMG can hold an HFS+ filesystem, and an HFS+ filesystem can represent files with resource forks. So, backward compatibility.
2. Because a DMG actually is a disk image, not a partition image—and therefore can represent a collection of volumes. If I recall, OSX's current "clean" install process effectively just takes a DMG containing {EFI, OS Base, Full Restore Image} volumes and uses the functionality of the "Erase and Overwrite with a DMG" option in Disk Utility to replace your disk's contents with it.
A gzip could represent HFS+ forks and attributes the same way the article is discussing - AppleDouble files and .DS_Store files. In fact, this is exactly what is done with zip files you create in the Finder.
Anyway, there's no way Apple is going to make improvements to the manual app install process anymore now that they have the App Store.
tar (which is what you mean) could do this, but until OSX Macs didn't ship with tar. DMG (technically the UDIF file format) came about as a continuation of .img files (the NDIF file format); there had already been built up some ecosystem around .img and .smi files and Apple wasn't going to suddenly switch to thinking in terms of tar files when they didn't have to.
Plus, a UDIF image can be simply passed to the kernel as a loopback image for a block device, and the files on it will then be discovered as plain files. For the same to work with tar or zip files, Apple would have had to introduce either something like the concept of Plan9/FUSE-like server processes that translate arbitrary backing stores into filesystem mounts; or break the universal abstraction of a filesystem by creating a higher-level shell namespace that could "see into" archives (like Windows and GNOME do) making OSX's Unix integration much less useful.
Mainly, though, it's that zip and tar are archival file formats. They're suboptimal for doing random-access updates on their contents, which is an important use-case of disk image formats. DMGs exist on OSX for the same reason that VHD(X)s exist on Windows: it turns out they're just a pretty great and flexible format for doing a lot of things OSes want to do.
The format itself also does a bit more than just a file archive, as it's a disk image format. You can do things like style the background and so forth.
>why apple doesn't have some sort of .app.gz "special"
In addition to other fine explanations provided, it did. The defacto standard was ".sit.hqx" -- BinHexed Stuffit archive, both third-party tools that survived into the OS X era. Disk Images came about when Apple finally realized the pain of delivering Mac apps over the internet.
Also, since I'm posting, OS X should really set the H attribute on these dot files when writing to a FAT drive, rather than relying on Unix shell convention.
Ah yes, good old .sit.hqx—compress something and then bloat it back up by converting it to ASCII. Luckily macbinary (.bin) took over at some point so that resource forks could be encoded without resorting to ASCII.
And you're right. Apple should definitely set the H bit on FAT volumes. Then no one would even notice.
Even if you really really think you need to ship a readme (Hint: No one reads them, and you don't) a zip is simpler and opens quicker.