The only thing I could think of would be that the low level bit/frame encoding scheme OR the higher level codec/vocoder were less error tolerant than other encoding scheme. But, that would be a problem regardless of band, xDMA, etc.
If the things I've read are true, the vocoder/codec is the same AMBE used by satellite phones and D-Star.
Sat phones are rumored to be quite clear and reliable when you have a satellite. I just ordered an Inmarsat phone, so I'll get to find how true this is Friday. I don't read of D-Star uses having anything remotely close to the issues I've heard myself and read about with OpenSky.
If I had to throw out a random, uninformed guess, I would point at the underlying CDPD encoding as the more likely culprit. Without knowing the guts of it, it wouldn't surprise me that a packet-data centric 'protocol' isn't cut out for the rigors of voice data.
Slightly along the lines of how a fast controller based wifi network isn't necessarily good for voice. Roaming issues between APs may not be noticed at all by data clients that have buffering and transparent (to the user) timeouts whereas voice and video conference clients will immediately notice drops.
With that in mind, it wouldn't surprise me to hear that OpenSky does OK for data. But, I can't imagine it's any faster than the data speeds available on a decently constructed P25, SmartNet/Zone, EDACS, etc. system.