Game (and other software) developers like to target stable APIs. Outside of the kernel, Linux has historically been incredibly unstable and fragmented. Vale shipped their own runtime libraries with Steam just to give native Linux game developers something consistent to target. If the Linux Desktop community solved that problem there might be more reason to make native ports.
In other words: there are a lot of steps and a lot of gotchyas to doing this that you're glossing over. Linux userland libraries are generally designed with the intention that an army of third-party maintainers will integrate all of this desperately developed software together and place it in a repo. Naturally every distribution wants to do things a little differently too, and they have a habit of changing it up every couple years. When you try to step out of that mold, even just to static link, things unsurprisingly become more difficult. Whereas Windows, Mac, Android, etc. have been designed since the beginning not to require that sort of thing and it is consequently a much, much more straightforward process.
I'm curious why, since you seem to believe the process is so straight-forward, you think it is that so few people distribute a simple binary? Why were Flatpak and AppImage invented?
Yes, if you link random libraries you find in /usr/lib you are going to have a bad time. And you can make things arbitrarily complex if you insist on compiling around the latest hot new distro and then try to hack your way around new symbols but even that is not an issue of fragmentation but an issue of the lack of an official SDK to target older glibc/etc. versions: you can't just target Windows 11 and then expect the .exe to run on XP.
But the "easy" solution is really that simple: compile on the oldest distro you want to support and statically link everything you can.
If you have additional requirements like needing a newer compiler or needing dynamic linking then there are more gotchas but even those are not really things that are hard to solve but rather things you need to be aware of.
And even those are all about ABIs not being forward compatible so you can't run things targeting newer system with older systems and instead need to take care to target the older ABIs that are still supported (or to remove unnecessary ABI depencencies). But that has nothing to do with fragmentation. You'd get that even if there was only a single distro.
Unless by fragmentation you mean that that no everyone is on the latest version supporting the ABI of your bleeding edge dev environment which is a ridiculous requirement that you only get if the ABI is frozen. Pretty much no platform has a forward-compatible ABI except if you count dead ones that don't change at all.
I do agree that toolchains should make it easier to target older ABIs. Something to control the target glibc version akin to the WINVER or _WIN32_WINNT macros would be really nice to have. But again, unless have some nonstandard requirements, just compiling on the oldest distro you want to support and statically linking most things works.
> I'm curious why, since you seem to believe the process is so straight-forward, you think it is that so few people distribute a simple binary?
Plenty peole do. Unity spits out such binaries (+data) most games outside of steam are distributed like this.
OSS projects often don't bother because they can get into distro repos. Some do though.
> Why were Flatpak and AppImage invented?
Besides sandboxing (which users care about, not apps), Flatpak and AppImage primarily make it trivial to distribute software that was designed for the distribution model where it depends on other libraries in the distribution. They also try to solve desktop integration which is not important for Games.
Even if you could not easily distribute binary software without Flatpak et. al, nothing is stopping devs from using those tools for games distribution so I hardly see how their existence is an argument for fragmentation making it harder .
