Suggested by Valve developer.
5 years ago LSI was created to fix some games using very old libraries, Steam games breaking with never Mesa and glibc versions, controllers not being detected.
It seems the original purpose of LSI is already done by Steam Runtime. It will already prefer system libraries if they are newer than those included in Steam Runtime, unless they are on a blacklist. It seems like it is a reasonable default, especially as with Steam or games updates some things get broken with our Native Runtime until we add a library to whitelist or blacklist, or fix an issue with one of our libraries.
So it used to be that games wouldn't run at all without LSI, after some system updates, now that is not the case. Also it used to be that game compatibility was higher with LSI, now LSI breaks game compatibility with newer solutions more often than fixes.
So I propose that LSI should be set to native runtime disabled by default. Because it still can be an useful tool, maybe providing some performance gains or it might fix some incompatibility in the future. Also I think it might fix a very old game that has some static libraries instead of using those in Steam Runtime. But otherwise it unfortunately hampers compatibility more than fixes.

For reference what Simon McVittie said.

I'm sure you know this already, but if this is the same as Arch's "native runtime" (disabling the LD_LIBRARY_PATH runtime and using host libraries exclusively), then this is unsupportable. Steam will continue to make changes and additions to its LD_LIBRARY_PATH runtime as they become necessary, and if OS distributors' "native runtimes" don't keep up with that, then Steam and games will not work.

If it brings you some sort of benefit, I would prefer it if we can find a way to get that benefit without it. The traditional LD_LIBRARY_PATH runtime already prefers to use host libraries in almost all cases, unless the library in the runtime is strictly newer (typically meaning libraries that we actively backport, like SDL and Vulkan-Loader) in which case using the newer version is required. The exceptions at the moment are libcurl, because of some historical ABI divergence that we're stuck with now, and a couple of 32-bit D-Bus-related libraries.

Using a "native runtime" will have little or no effect on the container runtime, which works differently anyway.