The compression on compression is an interesting question...
If the backup software placing data onto disk is sophisticated enough and it encounters a file with a zip header - does it "skip" compression for this file? I am not 100%.
I think that SQL 2008 and the compression that it does - has to deal with speed versus compression size, or the smallest .BAK file in a reasonably quick time.
Having said this, I believe that there is still a percentage of compression that can still be done on the compressed .BAK file (maybe only 50MB more on the 980MB file).
The fact is that the file is 28% of its initial size before the tape backup started this relates to:
* Quicker network transfer speeds to tape - if over a network
* Less data to process onto tape (less shoe-shine during compression of say 3.5GB)
* Potential header details within file describing construct of file that can be identified by backup software?
* Smaller storage on Disk (3 times more backup files can be retained than before)
But yes, more techinical analysis of backups and compression on compression would be an interesting concept to investigate and get real hard facts and figures for us all to understand.