I know this is dead, but I'm bored on a slow Saturday.
No, not in the same way. YCbCr is just a simple linear transformation of the color values.
A = [0.299 0.587 0.114;-0.1687 -0.3313 0.5;0.5 -0.4187 -0.08131];
RGB = uint8([100 100 100]);
YCC = uint8((A.*Asc)*im2double(RGB(:)) + os)
While in practice, you could use rgb2ycbcr(), the above demonstrates that the conversion is simple arithmetic. It's all just scaling and translation, no funny stuff.
In HSV or similar, you run into issues due to the polar model. What is the hue angle of a zero-length vector (when S = 0)? If saturation (S) is a normalized metric and the normalizing value is zero at the neutral corners, the meaningfulness of S collapses there since (e.g.) 50% of the distance from 0 to 0 is still 0. Does black lie on the neutral axis where S is 0, or does it lie on the surface of the cube, where S = 1?
There's nothing special about YCbCr in that sense. You can just as easily express YCbCr or LAB in polar coordinates and you'll have the same problem with hue ambiguity at the neutral axis. If you normalize the chroma axis, you'll have to make the same decision about how to handle the neutral corners.