it would be interesting to FC /b the files from your source material for master of orion against the files that have been copied to your CF device. This would tell us 2 things:
1) if any files are corrupt (duh)
2) that the reads of every file from CF are happening at a decent speed,
I can think of a few possibilities to explain a slowdown:
1) MOO (and windows 3.11) is doing a ton of tiny writes to temporary files as they start up. depending on where/how those files are allocated, the CF device may have to do a ton of read-modify-writes to update the file+fat. A disk cache, set in write back mode, can help with this. The cache will absorb the repeated hits to the FAT and won't write it physically to the media until after the storm is over. Depending on how full your CF device is will also impact the write performance. Since CF is so fast on reads, the disk cache can actually slow reads down, so you'd want to configure it to only cache writes, if possible.
2) The fuller the drive is+longer it has been in use, the more data it has to juggle around to wear level the device. Simply deleting files is not enough to free up the space, since we know DOS only deletes the files out of the FAT- the data is still there and the CF device cannot know that the file contents are no longer in use. This is why the ATA TRIM command exists, but sadly DOS doesn't know to use it. This, combined with #1, would make the problem worse. A DOS format will also not free up the space, since format mostly does verifies across the drive's sectors, and doesn't ERASE the blocks of flash. You'd probably need a manufacturer's utility to clean erase your CF device to properly create a fresh drive.
3) a file in your MOO or windows folder is sitting on a bad block and the CF is retrying repeatedly to read the data until it finally gets lucky enough to get the correct bits, causing the slowdown. This is less likely. the File Compare could show this either in extremely long read times to get the data or it will show data corruption in its output.