広範囲にランダムアクセスをするのでなければ、窓アクセスでもそこそこ使える。
オブジェクト指向なら見えないもの(privateやスコープ外)の方が多いのだから、
ランタイムがしこしこ貼り直してくれれば問題ない。
これを手動でやるとなると、実際には管理しきれないから、
単純なキャッシュ的使い方にするか、あるいはラッパを用意するかになる。
もちろんそれでもやりたい人はやれるようにAPIがあるわけだが。
> 大量のデータを操作するアプリケーションが、ハード ディスクの代わりにメモリにデータを維持することで、パフォーマンスが向上します。
https://msdn.microsoft.com/ja-jp/library/cc775523(v=ws.10).aspx

C/C++はメモリモデルがフラットで、リニアにアクセスできる前提だ。(ポインタは常にアクセス可能）
だから4GBの壁が直接見える。
C#とかはそもそもメモリモデル自体が必要ない。
変数はただの箱で、前回入れたものが出てくるだけ。共用体は禁止だ。
だから4GBの壁なんてものがそもそも存在しない。
ランタイムさえ対応すれば同じソースでPAE/AWEで15GBまでヒープ上に確保できることになる。
（C#のArrayは必ず添字チェックをしているため、ランタイム側で細切れに貼り直すことが出来、
結果、ユーザ側に15GBの一つのArrayを確保することも可能。)
ただしMSはこれを目指さなかった。

特に不思議なわけでもなく、ムキになる話でもないと思うが。
GCヒープ自体が一つのオブジェクトみたいなもので、get/setしかインタフェースを提供してない。
だからこういう事が普通に出来る。
（ただし繰り返すが、出来るのとやるのは別）