Well, the stable kernel interface matters on Linux because the user space doesn't give a damn about backwards compatibility. You might be fine if you only rely on the system libc. But every other library that you don't ship with your binary is essentially out to break your stuff. These libraries may even differ between distributions even though they have the same version numbers just because they were built using different build configurations. This is why things like the Steam Runtime exist.
> But every other library that you don't ship with your binary is essentially out to break your stuff.
There are many more lower level libraries that provide binary backwards compatibility: libasound, libX11, libGL, ...
Sure you're not going to be able to assume that /usr/lib/libpng.so.1 will provide the functionality that you want but that isn't any different from png1.dll some program installed in system32.
It's funny that you mention libpng. That is one of those libraries that is developed so conservatively that I'd actually trust it to provide the features a binary that I ship relies on. I rarely (if ever) needed the more obscure things like 16 bit per channels or ICC profiles.
That has nothing to do with kernel space vs user space and everything to do with different projects having different attitudes. The comparison is to the case where Linux instead ships a special "linuxso.so" that all processes and libraries need to (dynamically) link against in order to get a stable interface.
That attitude that is so prevalent in Linux user space is what this thread was getting at. This is why the syscall interface being maintained as a stable interface is so important on Linux compared to other operaring systems.
