There is nothing preventing you from writing an abstraction that supports both the fancy middleware as well as direct IP connections.
I can say this with certainty because I've also worked on multiplayer in several shipped multi-region cross-platform games, and this sort of arrangement is precisely what we have shipped. Granted, Direct IP connections are usually only supported on PC, but they are there, they do work, and our PC players appreciate that piece of mind.
I guess we could have made two different games at once, but we just needed one game that would work all the time for everyone. If we'd had the time or money to actually do that we would have used the time and money to made a completely new game in parallel.
I suspect you overestimate the amount of time or effort needed to write such an abstraction. Our base multiplayer abstraction is about 3k lines of C++, and once you have that in place there are a number of battle-tested low-level netcode libraries that can help implement the UDP subclass. Doing this also pays dividends during development, as it allows you to diagnose and fix issues with the application layer of your netcode far easier than having to navigate the authentication rigamarole of a middleware first.
Granted, I do realize that it is an additional lift. It helps that we reuse our engine between projects, and the games that we work on tend to be amenable to traditional client/server setups. We also don't support certain features over UDP, such as matchmaking or VoIP, and we also file the task of players actually finding and connecting to each other over UDP as "not our problem" unless they're on the same LAN segment. Our games also don't have in-game stores or microtransactions, so there's no digital goods to protect either.
However, in practice, the existence of the UDP layer was far and away the least difficult part of making a working multiplayer game. The most difficult parts are the same ones you run into on any normal multiplayer project - figuring out how to get the uber-flexible middleware you're using to play ball, solving the application layer bugs, and satisfying the certification whims of the platform owners.
I mean, sure, if we were forced to include end-of-life self hosting we could have shipped it with an early, janky QA build with most of the features that differentiated our game from others stripped out.
But why would we do that? It's not the game we designed, pitched, built, or advertised. It wouldn't be fun.
The hypothetical requirements I've seen throughout this discussion would result in whole categories of games either jacking up their prices or just skipping an EU launch entirely.
> The hypothetical requirements I've seen throughout this discussion would result in whole categories of games either jacking up their prices or just skipping an EU launch entirely.
That's not going to happen. Once the EU adopts some legislation, it will be likely that we will see the benefits of this downstream.
You can look to Apple and the EU regulations as an example as to why most publishers wont skip Europe.
Also you are not forced to include end-of-life hosting. You need to provide some form of a working game after it gets shutdown. Releasing server binaries, or something. Not just shutdown the game and giving your customers no recourse. Please remember that you have to sell some rights to the game, all we are asking for is that you not take away rights that were already sold.
I can say this with certainty because I've also worked on multiplayer in several shipped multi-region cross-platform games, and this sort of arrangement is precisely what we have shipped. Granted, Direct IP connections are usually only supported on PC, but they are there, they do work, and our PC players appreciate that piece of mind.