The idea of converting back and forth between two formats in a lossless way is nice, but this is not the situation we're talking about here:
(1) Original content is RGB.
(2) Studio converts to YCbCr.
(3) Studio subsamples Chroma.
(4) Studio applies lossy compression.
(5) Playback device uncompresses.
(6) Playback device upsamples Chroma.
(7) Playback device converts to RGB.
There's so much processing going on between formats (a) and (b) that this can never be even near to lossless. Which means that it's crucial that every processing step is done as good as possible, in terms of the *cumulative error*. Which means, dithering MUST be used, if you care about quality at all, even if RGB bitdepth is 8bit and YCbCr bitdepth is 10bit.
The situation might be different if you convert back and forth between (a) and (b) without ever doing any actual processing on the data. But there's no sense in doing that. And as soon as you process in format (b) and then convert back to format (a), you are in danger of losing quality if you have used rounding instead of dithering.
Which is not a problem at all, since this is all not lossless, anyway, due to lossy compression and chroma subsampling. We only have to keep the cumulative error as small as possible.
Nope. With my example, you have to use dithering both ways. Which means that 1/3 would become either 0.0 or 0.5. And 2/3 would become either 0.5 or 1.0. In other words, the final result would have about 25% 0.0 pixels, 50% 0.5 pixels and 25% 1.0 pixels. The cumulative error would still be near zero. Just the noise has increased. Which is exactly how dithering works. Ok, with my example the dithering noise is so high it's not funny. But this example is intentionally chosen with extreme values to make things clearer. Of course in real life dithering noise is so low that it's not visible to the naked eye.
Now let's get one step further: Imagine the data gets processed in format (b) by an algorithm which raises brightness of each value by one step. 0.0 becomes 1/3. 1/3 becomes 2/3. 2/3 becomes 1.0. 1.0 clips to 1.0. If you go (a) -> (b), then run this brightness increase algorithm, then go back to (a), if you use rounding, you'll end up with all pixels definitely being 1.0. If you use dithering, exactly the right amount of pixels would be 0.5 instead of 1.0, so that the overall brightness of the data would be 0.5 + 1/3 = 0.833333. (Or slightly higher than that, due to clipping).
Doesn't matter at all. We don't disagree on how to do RGB -> YCbCr conversion. We only disagree on how to convert floating point YCbCr to 10bit integer YCbCr. You want to use rounding. I advertize dithering. And there IMHO my example fits quite well (although of course it's grossly simplified)...