Outside of WCF it's not that different. I agree that the removal of WCF feels like a huge gut punch, but if you were following WCF tenets all along and had nice separation of your Data and Service and Operation Contracts it really shouldn't be that hard to drop all your WCF Binding wizardry and write new implementations of your contracts (interfaces) against HTTP REST or gRPC or GraphQL or Raw UDP Sockets or whatever your heart desires as your next communication tool, then dependency inject those implementations like any other dependency injection.
The point I was making was that WCF done well is a lot fewer billable hours to rewrite to use anything but WCF than people often think it is. I've done those rewrites before, and WCF is one of the few frameworks in existence that went so far out of its way to try to not leak abstractions that unless you were dependent on some truly baroque bindings, it's easier than most people seem to think. I've heard a lot of projects avoiding the .NET Framework to .NET 5+ transition solely because of WCF and how much work they think it would be based almost more on sunk "debts" feelings of existing tech debt from debugging WCF bindings/magic rather than maybe seeing it for what it is as more of a "unit testing DI exercise" where you've got existing test mocks (WCF) and just need a clean new implementation of existing interfaces.
Sure, but someone has to pay for that work, and many places don't have developers in-house, which means someone has to feel motivated enough to do a request to finance.