As long as you record at a high enough quality, compressing tape games shouldn't be a problem, especially for slow loaders. As far as I'm aware, the C64's standard loading scheme saves the status of each byte three times. When it loads in, it loads the same byte three times, and presumes that if two out of three are the same, that is the value it should use.
Of course, it's usually correct all of the time, so the easiest way to make a fast-loader is not to save the data three times. And then you can compress the data before saving.
So for slow loaders, MP3s should be able to use a relatively low bit-rate. For fast loaders, there is more of a chance of an error. As long as you keep the sample rate up quite high, it should be okay most of the time. MP3s are designed to remove audible frequencies, but data is not designed to be audible - just a stream of ones and zeroes.
The biggest problem I see is that you don't know if it's okay until you've tried to load it in, which could waste a lot of time.
A better method would be to read the data sampled from the tape and normalise the values so that they can be compressed using non-lossy compression (The .TAP format stores the time between each state change (one to zero or zero to one), then write a separate player for these files. Of course, then you can't play it back from your jukebox MP3 player to a real C64.
For MP3s, the most useful thing would be a verify program that can leap through the MP3 and compare it to the original data to see if it is all intact. That way you can check it before loading it in. Even better would be a specific MP3 compressor that uses VBR and verifies each block as it encodes. Then it can change the bit-rate for each block until it verifies correctly before moving onto the next one. That would give you the highest possible compression rate.
Went off on one there....sorry for that stream of consciousness.