Why should I do manual double buffering?

From MS:

For graphically intensive applications such as animation, you can sometimes improve performance by using a dedicated BufferedGraphicsContext instead of the BufferedGraphicsContext provided by the BufferedGraphicsManager. This enables you to create and manage graphics buffers individually, without incurring the performance overhead of managing all the other buffered graphics associated with your application, though the memory consumed by the application will be greater.

EDIT: I also found this article from Bob Powell which may be helpful:

Manual double buffering can be useful if you don't want the system so make assumptions for you such as whether the background is opaque or transparent or perhaps if you want to create a more complex buffering system. There are a few simple rules that you need to follow to get manual double buffering right.

First, don’t create a new back-buffer every draw cycle. Only create or destroy the bitmap when the window's client size changes. Second, only create a bitmap of the size you need. Clearing pixels takes time and so if there are more pixels than you need, you're just wasting processor cycles. Lastly, use the simplest draw method to copy the bitmap to the screen. DrawImageUnscaled is the way to go here.

EDIT: Another reason is that you may want the application to control buffering, not the controls themselves.

Source: Pro .NET 2.0 Windows Forms and custom controls in C#.

In WFA, double-buffering slows performance without completely eliminating flicker in custom graphics areas. For built-in GUI elements, like if you create a game built out of ImageButtons and Labels, the built-in double-buffered mode is great at hiding the redrawing of the control tree. However, there are a couple major problems with using it for a custom drawing area:

• The draw buffer created when you just set up the application to draw double-buffered is used to draw the whole window and all child controls, not just your custom drawing area, so you add the overhead of redrawing every GUI element on the back buffer before page-flipping.
• If anything invalidates the control, the Paint method is called. You may not be finished drawing when that happens and so you'll get an incomplete image shown to the user (not good in real-time graphics).

By keeping the basic window GUI single-buffered, but creating an area on which you control the buffering, both of these problems are minimized.

Double-buffering methods can be as simple as creating a Bitmap object as a back-buffer and drawing it to the draw area when you're good and ready, or setting up a seperate BufferedGraphicsContext to manage buffering of your custom draw area.