Even with a zero size game client, there is only so much to stream in textures and geometry. And when you're done with that, the game world itself is trivial.
The only thing in games that is bandwidth heavy is on-demand game asset delivery, which is highly cacheable and shardable. It will need no XDP-like networking tricks in either servers or clients.
Adding a possible example here to back Glen's comment. Larger render distance Minecraft servers, Bandwidth cost is un-predictable (Player movement based ex: Elytra, portals, joining) and scales squared! with the render distance.
In GTA V, each region has a custom-built low-rez model, and that's what you're seeing when you're more than about 200-300m away from it. Watch closely and see where the cars appear and disappear in the distance. That's the edge of the real rendering area.
I'm looking at doing this for a metaverse. In the GTA V era, those impostors were a manual job done by game devs. That needs to be automated.
Rather than doing mesh reduction on large areas, I want to take pictures of each area at high resolution from multiple angles, and feed the pictures through Open Drone Map to get a 3D mesh. The result looks like this.[1] For even more distant areas, those meshes can be consolidated into larger and lower-rez mesh tiles. It's the 3D equivalent of a slippy map. The amount of data you need to send is finite regardless of the world size, because the far-away stuff has lower resolution. The sum of that series is finite. This is similar to how Google Earth works when you get close enough to see 3D.
Handling a metaverse with user-created content is a big data-wrangling problem, but the compute and network loads are finite.
The only thing in games that is bandwidth heavy is on-demand game asset delivery, which is highly cacheable and shardable. It will need no XDP-like networking tricks in either servers or clients.