CRIBFMT is essentially a more accurate / higher-resolution presentation for the same data from CRIB/ELLH. As such the basic expectations should be, I think, as in all such cases:
CRIBFMT takes precedence if it exists.
CRIB/ELLH, if existing together with CRIBFMT, should still be as correct/accurate as possible, for machines that can handle them and don't handle CRIBFMT. In this case I think meaning that the CRIBFMT shape is contained inside the circle/ellipse defined by CRIB/ELLH (I'm assuming here that in general case for things that handle it more roughly it would be better to consider more of the lens as "important" rather than less, since the worse thing would be to remove/damage area that should be inside the crib).
That seems the natural way to handle all such differing presentations of the same data, regardless of specifics. Higher resolution takes precedence if both available and known/supported, lower resolution should still be accurate and err on the side of less severe consequences (when relevant).
( As an aside, I'm also not seeing how a device would have problem with both being present. At least not in cases when connecting to a VCA Host, rather than reading a file, after Initialization. CRIBFMT is only sent if explicitly asked for, and usually also CRIB/ELLH. If a device asks for both during initialization then it should be able to handle both.
This means that you shouldn't have to suppress CRIB/ELLH because if a device didn't explicitly ask for them then you probably shouldn't send them anyway. But it also means it should be usually very safe to suppress then, since if a device asked for CRIBFMT then it should be able to handle it and would probably prefer it anyway. )
It would be a good idea to slightly modify the standard to explicitly state the priorities/relationship if an ambiguity is possible. Obviously I think based on the same ideas. But in any case it shouldn't be a restriction on both being present, that would be unlike anything else (AFAIK) in the DCS, and the DCS does have other cases of different resolution/accuracy presentations of the same data. From a *correctness* aspect it should always be possible to send *everything*, and so even more so when it's everything that a device explicitly asked for.