WCF 从来都不是 COM 的替代品。.NET 框架本身就是 COM 的替代品。
WCF 旨在为编写客户端/服务器应用程序（例如 SOAP Web 服务和远程处理应用程序）提供一个通用接口，独立于所使用的协议/传输/序列化机制。
You can use WCF very efficiently by choosing the right behavior / serialization / protocol. Actually using COM/DCOM with dot-net will be less efficient today b/c of passing from dot net to com is slow.
我不知道有任何官方指南指定了 DCOM 的继任者，但 .NET 有两个框架可以替代 DCOM 的使用。它们是 WCF 和 .NET Remoting。
WCF 可以用来替代 DCOM 提供的所有传输功能等等。如果您处于无法使用 .NET 3.0 或更新版本的情况；您只有 .NET 远程处理可用。.NET 中的两个框架都允许您发出调用并将执行控制权转移到其他线程、进程和计算机中的主机。远程处理很可能是为了替代 DCOM，它也可以处理几乎所有的传输功能，但采用率并不高。
总的来说，现在大多数人更喜欢 WCF，因为一切都已明确定义，并且有大量功能可以控制通过 WCF 进行的调用的各个方面。现在，常规的 .NET 远程处理已经有些废弃了，因为您需要管理线路两端的类型信息 - 与 DCOM 相比，负担并没有显着改善。此外，它没有共享内存传输，因此线程内/进程内通信仅使用基于套接字的通信设置，并受到环回套接字性能的限制。
关于您提到的一般场景，几乎任何应用程序都可以通过 WCF 或 Remoting 连接到其他应用程序。大多数棘手的问题涉及与 Web 应用程序中托管组件的通信。通常，这通常不会完成 - 从它们发出调用，但很少在 http/https 网络活动之外被接受。安全和身份管理也可能很棘手，但比 DCOM 基于配置的设置有了很大改进。
总体而言，WCF 和 .NET Remoting 都明显优于 DCOM。它们更易于设置和维护，并且不像在 DCOM 下使用的 COM 组件那样令人头疼。此外，您还可以获得内在的好处，例如 .NET 中失败条件的自然库异常；而在 DCOM 中，您将不得不担心如何优雅地处理应用程序代码中的失败交付和超时。仅此一项就可以显着减少为处理此类情况而必须编写的代码量，并且通过异步调用，您还可以随时退出长时间操作。这在 DCOM 中做得很好是相当棘手的。
每项技术都有自己的优势。WCF 不能替代 COM。
使用 COM 的场景：
我们可以利用 .Net 应用程序中的现有技术。原因：如此多的组织（银行/电信/医疗保健系统）可能会在其自动化上投入大量资金。他们喜欢用最新的技术迁移（不是所有的业务流程，它应该是流程的一部分）。那么，就可以选择最新的技术了。但是，它们遵循现有代码的业务流程（代码可以是任何东西，COM...）。因此，它将降低开发成本、时间、调试和更多因素。每项技术都应该提供向后兼容性，否则将无法适应这个竞争激烈的世界。这就是.Net 引入互操作性的原因。（RCW、CCW 等）。