この手の解説は、プログラミングの解説をやっているHPにいけば、
詳しくされていそうですけれど、自分で調べてみたりされましたか？
そういう情報も質問時に添えておくとよりベターかと思います。

正確にはビットマップにするというよりメモリ上のDCにするというべきでしょうね。
メモリ上のDCで描画すると描画用のGDIを呼んだときに画面への反映をいちいちしません。
画面への反映（表示）は、メモリ上にある物を画面に合わせて色々と処理しているので
結構重い処理です。
メモリ上のDCの描画することによってその部分の処理が省かれるので描画そのものが
高速になります。転送時の都合上、メモリDC上にビットマップを指定しておいて
メモリDC上の内容を実画面に転送するとその時のみ表示用の変換処理を行います。
その結果、描画が高速になると考えていいかと思います。

ありがとうございます

>正確にはビットマップにするというよりメモリ上のDCにするというべきでしょうね。
DC はどれをとってもメモリー上の何者かでしかないはずでしょう。DC は Windows が
提供する共通の描画インターフェースだからです。デバイスコンテキストという抽象的
な境界層を介する事で描画という操作に装置独立性を導入しようとしているのですね
このように考える場合、あなたの上の表現はかなり不正確です。ほとんどの装置では
(その装置に対応した) DC に選択したビットマップに対して描画する（描画結果は DC
に選択したビットマップにしか残らない）のですから

GetDIBits()/SetDIBits()系のAPIはWinG由来ですから、基本的には速い
と考えてよいでしょうね。
やねうらお氏のHPにこの辺のディープな話がありますよ。

画面を表示する＝ビデオカード上のメモリ（以下 V-RAM）へ書き込む、なわけですが。

システムメモリ→ V-RAM は
「違う機械の上に乗っているメモリへの転送」
であるわけで、これがボトルネックになりそうですね。

なら、ここでの転送量を極力抑えるにはどうしたら？

まあ、最速を求めるなら DirectX 使って
V-RAM → V-RAM のような気がしますが。

思いつきなんで間違ってたらゴメンなさい。

メモリDCをつかった、描画への高速化なんですが
ウインドウ、ウインドウDC、ビットマップ、メモリDC、データ、描画
という単語を使うとどのような説明が一番適切でしょうか？

自分もデバイスコンテキストというものがどんなものなのかしっくりきません

このへんの説明をわかりやすくしてくれる人いたら、うれしいですね