[XPERIA X8 Q&A, Help & Troubleshooting] :
Yes, you're right that a FTF is a zero-compression level ZIP (-0 commandline parameter of PKZIP which means "store only"). Ignore the slight difference in packed and unpacked size, that's just the PKZIP header and metadata:

$ zipinfo ./X8_E15i_Baseband_015.ftf
Archive: X8_E15i_Baseband_015.ftf
Zip file size: 27949955 bytes, number of entries: 8
-rw---- 2.0 fat 107 bX defN 11-Mar-03 08:29 META-INF/MANIFEST.MF
-rw---- 2.0 fat 408307 bl defN 11-Mar-03 08:29 amss_fs.sin
-rw---- 2.0 fat 731045 bl defN 11-Mar-03 08:29 fota1.sin
-rw---- 2.0 fat 639 bl defN 11-Mar-03 08:29 cache.sin
-rw---- 2.0 fat 6181914 bl defN 11-Mar-03 08:29 kernel.sin
-rw---- 2.0 fat 731045 bl defN 11-Mar-03 08:29 fota0.sin
-rw---- 2.0 fat 19792794 bl defN 11-Mar-03 08:29 amss.sin
-rw---- 2.0 fat 98883 bl defN 11-Mar-03 08:29 loader.sin
8 files, 27944734 bytes uncompressed, 27949017 bytes compressed: [COLOR="Red"]0.0%[/COLOR]

APKs, in this example the signed version of the xRecovery installer, are compressed.

$ zipinfo ./xRecovery_Installer_v0.1.apk
Archive: xRecovery_Installer_v0.1.apk
Zip file size: 1712242 bytes, number of entries: 19
-rw---- 2.0 fat 1249 bX defN 11-Jan-15 06:08 META-INF/MANIFEST.MF
-rw---- 2.0 fat 1302 bl defN 11-Jan-15 06:08 META-INF/CERT.SF
-rw---- 2.0 fat 1714 bl defN 11-Jan-15 06:08 META-INF/CERT.RSA
-rw---- 2.0 fat 4432 bl defN 11-Jan-15 06:08 resources.arsc
-rw---- 2.0 fat 14368 bl defN 11-Jan-15 06:08 classes.dex
-rw---- 1.0 fat 694 b- stor 10-Dec-15 20:52 res/drawable/warning_16.png
-rw---- 2.0 fat 2740 bl defN 11-Jan-15 06:08 res/layout/main.xml
-rw---- 2.0 fat 735308 bl defN 11-Jan-15 06:08 res/raw/busybox
-rw---- 1.0 fat 1984 b- stor 10-Dec-15 20:52 res/drawable-ldpi/icon.png
-rw---- 1.0 fat 1009 bx stor 10-Dec-15 20:52 res/drawable/block_16.png
-rw---- 2.0 fat 1668 bl defN 11-Jan-15 06:08 AndroidManifest.xml
-rw---- 2.0 fat 2263040 bl defN 11-Jan-15 06:08 res/raw/xrecovery.tar
-rw---- 1.0 fat 3797 b- stor 10-Dec-15 20:52 res/drawable-mdpi/icon.png
-rw---- 1.0 fat 1116 b- stor 10-Dec-15 20:52 res/drawable/info_16.png
-rw---- 1.0 fat 1005 b- stor 10-Dec-15 20:52 res/drawable/search_16.png
-rw---- 2.0 fat 471 bl defN 11-Jan-15 06:08 res/raw/chargemon
-rw---- 1.0 fat 617 b- stor 10-Dec-15 20:52 res/drawable/tick_16.png
-rw---- 1.0 fat 6314 b- stor 10-Dec-15 20:52 res/drawable-hdpi/icon.png
-rw---- 2.0 fat 596 bl defN 11-Jan-15 06:08 res/menu/mainmenu.xml
19 files, 3043424 bytes uncompressed, 1709796 bytes compressed: [COLOR="red"]43.8%[/COLOR]

The same goes for xRecovery and CWM update ZIPs, they are actually compressed to reduce filesize - and of course .jar files are also compressed.

As for the browser ZIP vs FTF glitch - that most likely happens when the browser decides that since the web-server reports a "application/x-zip" header the extension should therefore be .zip and not something else (like .ftf). That is actually a somewhat lousy configuration of the web-server software in question as one can influence what the server reports in relation to extensions (i.e. setting .ftf to "application/x-binary").

Like we already worked out IE and Opera are notoriously known to tinker around with file extensions based on the header they get from the web-server - Firefox and Chrome/Chromium honor the filenames as given by the web-server.