I think for typical JS/CSS/HTML sizes, and decompression times, probably maximum compression ratio, followed by decompression speed is what I'd look for. I don't care too much about compression speed, in the sense that if I have to spend 1 minute compressing JS to crunch it by 10%, but I serve that file a million times, then as long as decompression doesn't negate the gain in network time saved, it's a win.
I guess the other factor for mobile is, besides memory and decompression speed, how do various compression schemes fare battery wise?
Regarding decompression times, I think it's much more important to save transferred network data than to prioritize quicker decompression.
HTTP request times have a long tail; they can get really slow for the many, many people limited to slow connections. Decompression times are going to be much more consistent. Our aim here should be to improve the 10% slowest requests, and you do that by optimizing the actual transfer.
I guess the other factor for mobile is, besides memory and decompression speed, how do various compression schemes fare battery wise?