这取决于您的需求。
使用 CLR 将为您提供最具表现力的库集（整个 .NET 框架），但代价是将您的可执行文件限制为要求在运行时安装 .NET 框架，以及将您限制在 Windows 平台上（但是，所有列出的 4 种技术都只是 windows，因此平台限制可能是最不麻烦的）。
但是，CLR 要求您使用 C++ 语言的 C++/CLI 扩展，因此本质上，您需要学习一些额外的语言特性才能使用它。这样做可以为您提供许多“附加功能”，例如访问 .net 库、完整的垃圾回收等。
ATL 和 MFC 之间的选择有些棘手。我建议您参考MSDN 的页面进行选择，以便在它们之间做出决定。ATL/MFC 的好处是您不需要 .NET 框架，只需安装 VC/MFC 运行时即可进行部署。
直接使用 Win32 提供了最小的可执行文件，具有最少的依赖项，但需要编写更多的工作。您拥有最少数量的帮助程序库，因此您编写的代码更多。
Win32 是原始的裸机方式。它乏味，难以使用，并且有很多小细节需要记住，否则事情将以相对神秘的方式失败。
MFC 建立在 Win32 之上，为您提供一种面向对象的方式来构建您的应用程序。它不是 Win32 的替代品，而是一种增强功能 - 它为您完成了很多艰苦的工作。
System.Windows.Forms（我假设您是 CLR 的意思）完全不同，但与 MFC 的基本结构有很大的相似之处。到目前为止，它是最容易使用的，但需要 .NET 框架，这在您的情况下可能会或可能不会成为障碍。
我的建议：如果您需要避免使用 .NET，则使用 MFC，否则使用 .NET（事实上，在这种情况下，我会使用 C#，因为它更容易使用）。
就 C++ 而言，我会使用 WTL。它是轻量级的，您将几乎没有（如果有的话）依赖项，使其易于运输和安装。当我的应用程序包含一个可以在大多数版本的 Windows 上运行的 EXE 时，我发现它非常令人满意，但这可能不是您关心的问题。
如果您选择改用 .NET，那么 C# 几乎可以肯定是要走的路。
WTL 中的更多内容：
我会很好奇为什么你会在 C++ 中这样做。根据您的简短描述，C# 听起来像是一个更合适的选择。
只是为了详细说明一下，请查看您提供的描述 C++ CLR 的链接。评分最高的答案指出（准确地说，在我看来）C++ 适用于“内核、游戏、高性能和服务器应用程序”——这些似乎都没有描述你在做什么。
从某种意义上说，MFC、ATL 等将得到支持，是的，您将能够在未来版本的 Visual Studio 上编译您的应用程序并在未来版本的 Windows 上运行它们。但从某种意义上说，它们不受支持，因为 API 或语言中没有像 CLR 和 C# 中那样进行很多新的开发。
CLR 没有任何问题。像这里的其他人一样，我建议使用 C#，但是由于您有理由坚持使用 C++，因此如果您还不熟悉它们 (IMO)，那么使用 .NET 框架比使用 ATL/MFC 容易数千倍。
值得一提的是，如果您使用的是 C++/CLR，那么您根本就没有真正使用 C++。C++/CLR 像 C# 一样编译成 CIL。我自己从未使用过它，但我相信它的目的是允许您编译遗留代码并使其易于用于新的 .NET 代码，而不是允许新代码与旧的 C++ 可执行文件一起使用。还有其他从 .NET 调用本机代码的方法，也许您应该探索一下。
这个问题的现代（2021 年）答案似乎是使用 C++/WinRT 而不是 C++/CLR（或 C++/CLI 或 C++/CX ... jeez Microsoft）：
https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/intro-to-using-cpp-with-winrt
C++/WinRT 是用于 Windows 运行时 (WinRT) API 的完全标准的现代 C++17 语言投影，实现为基于头文件的库，旨在为你提供对现代 Windows API 的一流访问。借助 C++/WinRT，您可以使用任何符合标准的 C++17 编译器来创作和使用 Windows 运行时 API。
...
C++/WinRT 是微软推荐的 C++/CX 语言投影的替代品
它基本上是标准的 C++，但 UI 是用 XAML 定义的。
尽管如此，与其他答案一样，使用 C# 似乎确实是微软最喜欢的方法。无论如何，C++/WinRT 看起来真的几乎是 C#。