One thing to remember is ROMs themselves tend to have encoded/compressed data. For example, a common compression method used on these cartridge-based systems is RLE (Run-Length Encoding). This is useful for graphics. Not everything can be encoded in this manner, like program code. However, it was one of the many tools developers would use to make the most of limited ROM space.
An advantage PCs typically enjoy is many orders of a magnitude of available RAM. It's trivial for a PC to take a zipped rom image, decompress it in RAM, then run an emulator. With 1MB (8Mbit) on the MED Pro, that's not universally enough space for a run-in-ram approach. ROMs aren't built with a standard to define data types, just memory addresses and some parts of code expected to be at those addresses. It would be a large undertaking to find a way to standardize a ROM's format just with the sole purpose of compressing it for low-memory devices. Given the size of the Genesis/MegaDrive library, it's really cheap to put it all on an SD card.
Now, with Sylver's idea of CHD for SegaCD/MegaCD is a very different idea to use a format that's fundamentally designed to store structured CD sector data. CHD allows for decompression of required data on-the-fly, which would be ideal for a low-memory device like the MED Pro.
I wrote this to help provide some color to this subject. Compression in some form was almost always used in the 16-bit era. But not the type we're generally familiar with / spoiled by modern PCs.
