The wikipedia example is a very nice example, but ironically, can lead to a lot of confusion, as well. It should be noted that the 24-bit gradiant example achieves a nicely smooth gradiant (ymmv, depending if you are viewing on an LCD or CRT), so that should suggest that the bit depth of the color used in these enduser formats is quite sufficient to do the job (naturally, footage capture and mastering should continue to strive at a higher bit depths, to ensure that the best of 24-bits can make it to the consumer). "Deep color" would not solve the problem, if the problem is occuring elsewhere. It would just result in even more bits getting "lost" at the problem point, rather than more bits making it to the end result. The problem point is lossy compression, which attempts to eliminate finer bit depths it thinks we would not see, if they were missing from the picture. The result is a reduction in data size, but also the subtle loss (or sometimes not so subtle) of intermediate shades of color which would smoothly fill in a gradient. What's left is a gradient with clearly visible steps, where adjacent colors fail to blend together. It's not that 24-bit color is not enough. It's the lossy compression that leaves the end result with only a subset of colors
available from that 24-bit color pallette.
So what of this "confusion" I mentioned earlier? The Wikipedia example chooses a single primary color of red to show a gradient. Hence, it is no longer using the "full" 24-bits to achieve that color. It is only using 1 of three primary components, since it is red. Technically, this isn't a 24-bit gradient, but an 8-bit gradient (since the red only can utilize 1 channel out of the 3).
So it is actually possible to show a pretty smooth gradient of a single primary color with a "mere" 8-bits of actual data (shown in the 3rd figure). So what about the very coarse gradient that is labeled "8-bit gradient"? Why is it so coarse at 8-bit (the 1st figure), when I just explained that 8-bit is enough to show the color red in a very smooth gradient (the 3rd figure)? The answer is that the 1st figure is not
technically using all 8-bits to achieve that gradient in that color. Just like before, the color red corresponds to 1 of 3 available color channels. So it is only a sub 3 bits out of 8 bits that are getting used to show the red gradient. If you count the shades in the coarse gradient example, you see it works out to 6 discrete shades, which is what would be possible in a colordepth greater than 2 bits but not quite 3 bits (4 shades vs. 8 shades).
Naturally, if the example used a color resulting from a mixture of red, green, and blue, then all 3 channels with their associated bits would get a work out, and the labeling of 8-bits and 24-bits would be more technically valid.
Also forgot to mention, the whole situation as it relates to incidences of banding on PE gets even more complex, as the bits get shuffled here and there when/if a colorspace conversion has to occur during the production process between rgb and yuv, or vice versa. Shades of colors don't match up quite right between the 2 systems, so therein lies another opportunity for subtle color information to get lost/mangled between generational cycles. The end result is, again, color performance which is only using a subset of what would be available in a fully intact 24-bit pallette.
There are even colors in one system that are outright illegal in the other color system. In this scenario, I believe this applies to the high intensity shades of the primary colors, rather than the near black intensities. So it is certainly possible for high saturation colors to get clipped to a lower level when converting between colorspaces.
So it is possible that the right scenario gives a double whammy in sacrificed color depth. You lose some bits on the low end, get clipped on the high end, and maybe the end result has to contend with a shockingly limited color range of that possible with a fully intact 24-bit pallette.