The YCbCr model has a few variations in different application contexts, but essentially they are all some affine (linear) transformation on the RGB color data. If you think of the RGB space in terms of a 3D cube, with its sides representing the R, G and B axes (for JPEG, their range would normally be from 0 to 255), then each pixel in your image corresponds to a 3D point inside the cube, where its color component values are the point's coordinates. This forms a "cloud" of points inside the cube.
Examining many normal images in this representation shows that the clouds tend to have some common shape, where most of the points are concentrated along the main diagonal (more or less) of the cube. So, if we now rotate the cube (our reference axes system) such that its first axis is aligned with the long axis of the cloud we now have a new set of point coordinates where the first coordinate carries most of the information and the other two carry less information.
The first coordinate happens to carry the intensity value of the pixel where the other two coordinates correspond to the color information of the pixel. Grossly, these constitute the Y (luma, intensity), Cb and Cr (chroma) components of the YCbCr representation of the color of the pixel in the image.
There are a couple of outcomes from this. First, you can take the Y channel and directly display it as a gray scale image. Then, as @forsvarir commented, we can discard some of the color information and still have acceptable image quality - which helps us to get better compression ratios.
The origins of this kind of pixel representation dates back to the days of transition from B&W to color TV broadcasts, where backward compatibility was required so that people who did not upgrade their sets would be able to watch color programs in B&W. The solution was to remain with the intensity (i.e. B&W) signal and superimpose some color components on top of it. This way, the B&W tuner could still use the broadcast signal with some acceptable level of distortions.