2つのライブラリーがどのようにして生まれ、どのように進化してきたかを振り返ると、質問に対する答えはほとんど歴史的なものだと思います。
簡単な答えは、「空想」を何もしていない場合は、ATLを使用することです。COMがスローされた単純なユーザーインターフェイスに最適です。
長い答え：MFCはC ++と呼ばれるこの新しい言語を試し、それをWindowsに適用するために90年代前半に構築されました。OSにまだないようなOfficeのような機能を開発コミュニティで利用できるようにしました。
[装飾を編集する：私はMicrosoftで働いていなかったので、OfficeがMFC上に構築されたかどうかはわかりませんが、答えは「いいえ」です。勝利3.1、勝利95日目に戻って、Office UIチームは新しいコントロールを発明し、それらをライブラリにパッケージ化し、WindowsおよびMFCチームはラッパーとAPIを再配布可能なdllを備えたこれらのコントロールに組み込みました。これらのチーム間でのコラボレーションとコードの共有が少しあったと思います。最終的にこれらのコントロールは、サービスパックまたは次のWindowsバージョンのベースオペレーティングシステムに組み込まれます。このパターンは、Officeが出荷された後にアドオンコンポーネントとしてWindowsに追加されたOfficeリボンでも継続され、現在はWindows OSの一部となっています。]
その当時、ライブラリはかなり原始的でした。これは、C ++言語とコンパイラが新しく、MicrosoftがOfficeの進化に伴ってライブラリを構築していたためです。
この歴史のおかげで、MFCは次のことを行います。
- かなり不格好なデザインです。それはWindows APIの軽いラッパーとして始まりましたが、成長しました。コンパイラと言語がそれらをサポートしていなかったために発明されなければならない小さな「機能」がたくさんあります。テンプレートはなく、文字列クラスを発明し、リストクラスを発明し、独自のランタイム型識別を設計しました。
- 20年にわたるOfficeおよびWindowsの進化をカプセル化します。これには、おそらく決して使用しないだろうすべてのがらくたが含まれます。単一および複数のドキュメントインターフェイス、DDE、COM、COM +、DCOM、ドキュメントのリンクと埋め込み（したがって、Wordドキュメントを必要に応じてアプリ）、ActiveXコントロール（Webへのオブジェクト埋め込みの進化！）、構造化ドキュメントストレージ、シリアル化とバージョン管理、自動化（VBAの初期の時代から）、そしてもちろんMVC。最新バージョンは、Visual StudioスタイルのウィンドウドッキングとOfficeリボンをサポートしています。基本的に、レドモンドの20年後のすべてのテクノロジーはどこかにあります。それだけで巨大です！
- ちょっとした落とし穴、バグ、回避策、前提、まだ使用されていないものをサポートし、問題を引き起こします。多くのクラスの実装と、それらがまともなサイズのプロジェクトで使用するためにどのように相互作用するかをよく理解している必要があります。デバッグ中にMFCソースコードを掘り下げることは一般的です。ポインタがnullでクラッシュを引き起こす15年前のテクニカルノートを見つけることはまだ起こります。古代のドキュメント埋め込みに関する初期化の前提は、奇妙な方法でアプリケーションに影響を与える可能性があります。MFCには抽象化などというものはありません。日常の癖や内部を操作する必要があります。何も隠しません。クラスウィザードを開始しないでください。
ATLは、C ++言語の進化とともに発明され、テンプレートが登場しました。ATLは、MFCライブラリの実行時の問題を回避するためにテンプレートを使用する方法のショーケースでした。
- メッセージマップ：これらはテンプレートベースであるため、型がチェックされ、バインドされた関数を台無しにしても、ビルドされません。MFCでは、メッセージマップはマクロベースで、実行時にバインドされます。これにより、奇妙なバグ、誤ったウィンドウにメッセージがルーティングされる、関数またはマクロが正しく定義されていない場合にクラッシュする、または何かが正しく接続されていないために機能しない可能性があります。デバッグするのがはるかに難しく、気付かずにブレークするのが簡単です。
- COM / Automation：メッセージマップと同様に、COMは元々マクロを使用してランタイムにバインドされていたため、多くのエラー処理を必要とし、奇妙な問題を引き起こしていました。ATLにより、テンプレートベースでコンパイル時間に制限があり、処理がはるかに簡単になりました。
[装飾の編集：ATLが作成されたとき、Microsoftの技術ロードマップは主に「ドキュメント管理」に焦点を当てていました。Appleはデスクトップパブリッシングビジネスで彼らを殺していました。Officeの「ドキュメントのリンクと埋め込み」は、Officeの「ドキュメント管理」機能を強化してこの分野で競争するための主要なコンポーネントでした。COMは、アプリケーション統合のために発明されたコアテクノロジであり、Document Embedding APIはCOMに基づいていました。この使用例では、MFCの使用は困難でした。ATLは、この特定のテクノロジをサードパーティがCOMを実装し、ドキュメントの埋め込み機能を利用しやすくするための優れたソリューションでした。]
これらの小さな改良により、MFCの機能のようなオフィスのすべてを必要としないシンプルなアプリケーションでATLを非常に簡単に処理できるようになります。シンプルなUIといくつかのOfficeオートメーションが組み込まれたもの。それは小さく、高速であり、コンパイル時間に制限があるため、多くの時間と頭痛を節約できます。MFCには、扱いにくい、扱いにくいクラスの巨大なライブラリがあります。
残念ながらATLは停滞した。Windows APIとCOMサポート用のラッパーがあり、それを超えることはありませんでした。Webが始まったとき、これらすべては古いニュースとして忘れられていました。
[装飾の編集：マイクロソフトは、この「インターネットシング」が大きくなることを認識しました。彼らの技術ロードマップは劇的に変化し、Internet Explorer、Windows Server、IIS、ASP、SQL Server、分散トランザクションサーバーのCOM / DCOMに焦点が当てられました。そのため、ドキュメントのリンクと埋め込みはもはや最優先事項ではありませんでした。]
MFCの巨大なフットプリントにより、ダンプすることが不可能になり、それでもまだゆっくりと進化しています。テンプレートがライブラリに組み込まれ、他の言語とAPIの機能強化も行われました。（私はこの質問を見るまでWTLを知りませんでした。:)
最終的に、どちらを使用するかは、単に好みの問題です。ライブラリに適切なラッパーがない場合、必要な機能の大部分はベースOS APIにあります。これは、ライブラリから直接呼び出すことができます。
MFCを何年も使用していることに基づいた私の2セントだけで、現在は毎日使用しています。2、3のプロジェクトで最初にリリースされたとき、ATLに手を出しました。当時は新鮮な空気でしたが、どこにも行きませんでした。その後、Webが登場し、すべてを忘れてしまいました。
編集：この答えは驚くべき長寿を持っています。それは私のスタックオーバーフローページにポップアップし続けているので、私は不足していると思った元の回答にいくつかの装飾を追加すると思いました。