Effort in this regard with any app of substance will most likely prove to be in vain --- either now or in the very near future.
Why do you say this? I am truly curious.
My understanding is that the Linux ABI is very stable ("we never break user space" -- Linux Torvald). If you static link the libc, your binary should work on any Linux.
I mean, if we were to judge Linux it should be with regards to other operating system of equivalent complexity and use. My understanding is that Windows or macos do not offer this kind of stability over time.
For example, applications that need to do hostname and username resolution have to interface with NSS, and that breaks if you statically link glibc.
Another example is playing audio - this requires interfacing with some userspace audio system like JACK, PulseAudio, or now Pipewire. If you statically link libSDL, it won't work in 5-10 years with whatever the latest fad in audio playback is. But if you dynamically link libSDL, then you can't statically link glibc because libSDL may be linked with a newer version of glibc, causing a conflict.
Thus you end up with a quite a mess.
The kernel interface is very stable. The common libraries are not. Not even glibc
This definitely torpedoed your argument (ask any enterprise Windows user). First, "Linux" in this sense means what a normal user sees as Linux, which is a GNU/Linux desktop with a DE such as Gnome or KDE. You're correct that the Linux kernel ABI is stable (at least in userland), it would be simply wrong to say that "Linux" (as would normal users encounter) is ABI-stable.
If you run HPC jobs, you are stuck with the Linux version your cluster supports (probably not too recent), and you probably won’t be able to build directly there. This is when you need all these hacks.