Man...
That's a lot of info, but honestly, if you ask me, it's all kind of missing the target.
Here's why
any device can reproduce CMYK or RGB files:
Because CMYK and RGB in this context only refer to the pixel definitions of the file. That's it. End of story.
Leave it at that and then let color management do the rest. If you do color management correctly, it will work.
Of course you've got to go beyond just RGB and CMYK and ask what RGB and what CMYK, and once you do -- and there's no getting around it -- then every CMYK value and every RGB value in every RGB or CMYK file represent some L*a*b* value, and it's that value that matters, not its numeric representation in whatever CMYK or RGB space the file is in. You can actually think of that representation as just a placeholder in the file for the true L*a*b* (or occasionally XYZ) value.
And, if you get a poor transform from RGB to CMYK,
then the fault is in how you're managing the transition. Period. It is not that the final device is incapable of accepting the file.
There is no device that's incapable of accepting RGB files. Anyone who says otherwise is misinformed.
Interestingly, did you ever hear anyone say: "My monitor is RGB, I can't use it to display a CMYK file"?
Makes just about as much sense as saying you can't send any printing device an RGB file.
(Edited to add: Oh, and of course it needs to be said...
RGB has a larger gamut than CMYK...
That is not true. Because by its nature CMYK is reflective and by its nature RGB is transmissive, and since light tends to get more diffused in reflecting than transmitting, it is true that many RGB color spaces have larger gamuts than many CMYK color spaces. This is especially true with most of the standard RGB and CMYK working spaces.
But it's certainly possible to have a small gamut RGB color space (a laptop monitor, say) that is smaller than a large gamut CMYK color space (say an aqueous inkjet on gloss stock, or even a solvent inkjet on cast coated.)
Mike Adams
Correct Color