It might have been a concern long ago when space was a premium, but these days in the world of >=1TB drives you could probably build your entire software library in the most horrifying, space inefficient way, and it would still be completely and utterly dwarfed by the user's media library. Excepting games, I would bet most anyone's software library would likely comfortably fit under 128 GB. The photos, games, music, and video would be what necessitates more. And I suspect even then, a lot of people don't bother to store these things locally besides the games and photos.

The majority of a game's data usage comes from assets. The binary is a tiny fraction of the size of the application.

The game binary is generally completely worthless without its associated assets, though. Nobody would really want to install Skyrim without the master esm since the assets contained therein are essential to the experience. Maybe that's not particularly useful to the discussion, but my point is you could probably fit all your most commonly used programs in a static format + all your average assets like icons or config files, and run and use them in a pretty small amount of space. The games, FLAC music collection, high quality photo library, etc can very easily be much greater a storage requirement than an application library full of static binaries.

The idea with oasis is to choose smaller software with fewer dependencies that offsets the slightly higher disk usage, as well as to deliberately not have thousands of binaries.

Yes, I would think static linking would lead to higher disk usage for binaries.

That analysis doesn't really answer the question re: disk usage and doesn't really quantify how much sharing there is from shared libraries, just how many shared libraries don't get shared... basically "Do your installed programs share dynamic libraries" is answered as "not really" because there s a long tail of libraries that are not widely shared.

Drew's stats shows 80% of binaries link to libc (1.8MB on my system), which by itself could be "a lot" of extra storage. It wouldn't be 80% * 1.8MB per executable if unused symbols weren't linked, but still

The problem is not the size, but for Linux distributions to provide fast security updates for shared libraries instead of having to patch and recompile tons of packages.

That also depends on how the libraries are structured. As far as I know, if you were to successfully link in glibc, that would include the entirety of it, however musl libc is structured so only the parts (at function level?) are linked in.