Usually, when a non-compressed image is used as a boot time kernel, it is in an embedded device, where processor resources to uncompress the image are scarce.
http://www.linuxquestions.org/questi...oblems-546420/
To my knowledge, grub will not load an uncompressed image without a source patch. There are several other, simpler boot loaders out there that will, however.
As to
why, well, that's a more fertile subject.
The most important reason is the way in which most PCs read the image from the disk before decompression and booting. (Through the BIOS with no OS, so usually the most basic transfer mode that the controller can do ... SLOW.) Compressed is smaller and smaller is quicker. A lot of newer SATA controllers aren't hampered by this as much, but it still seems to be an issue, even if it's a smaller one.
You should see my old ThinkPad boot up Slackware-current ... It takes a total of 134 seconds to reach an X11 login screen. 96 of those 134 seconds are spent waiting for the IDE controller to load up the compressed kernel image. It's painful.
The second most important reason is a legacy one. Older PCs (386, 486, Pentium, Pentium II, etc) could only read the first so many cylinders of the hard drive when the BIOS was in charge of disk access. For this reason, it was paramount that the kernel image, however large it actually was, fit into the first few megabytes of the disk, hence the compression.
