If you really understand how the color spaces work, you'll see that that's technically nonsense. Yes, it makes perfect sense to a layman, but good luck coding it!
For example, where you see "orange", a computer only sees numbers:
- RGB: Red = 100%, Green = 50%, Blue = 0%
- HSV: Hue = 30deg, Saturation = 100%, Value = 100%
- YCrCb: Luminance = 57%, Chrominance_Red = 27%, Chrominance_Blue = -31%
This is using the BT.709 standard for YCrCb. Other standards exist too, which give slightly different results.
- If you've somehow encoded some other information in the RGB channel values because those are the most accessible for you or because our eyes see that directly, then of course you'll want to use that.
- If you're looking for a specific color in a scene, regardless of lighting, then HSV or something similar might be good. RGB is terrible for that.
- YCrCb is often used in broadcast because it provides the brightness directly and the color separate from that. Once that exists, the two sets of information can be encoded differently, to preserve the brightness more than the color. (this was even true in analog TV, to be backwards-compatible with black-and-white sets) OBS's default is NV12, which is a specific version of this. If you're detecting something related to the details of broadcast, then you'll probably want to use this one.
Etc.
The different color spaces don't really matter as much for picking the color to start with, as the software can easily do that conversion. The trouble comes in specifying the tolerance. It's completely different, for just one example, to specify a color in a scene as range of Red, a range of Green, and a range of Blue, than it is to specify a range of Hue, and completely ignore the Saturation and Value.