That's cool, but with disk space and memory being as cheap as they are, is this still a big deal in anything but the smallest of embedded environments?
And re:memory, it's pretty tight on most end-user machines. By default, most laptops only come with 4-8GB of RAM. And in the cloud, memory cost is perhaps even more expensive. On ec2, a 'large' instance usually has only between 4-8GB of RAM. The default small instances have only 2GB of RAM, which doesn't give much room left over for applications after you account for the OS and various utilities.
It can definitely add up.
0) As programs are expected to do more or run faster, they are required to use more computational power and memory. As examples, this is especially true of 3D Rendering or Video Editing software.
1) Because of the price and abundance of hardware - many programmers have stopped caring about nearly all optimization unless it brings their program to a halt. Requiring more computational power and memory to run many of these programs.
To many people $50-$60 for 8GB of 2x4GB DDR3 RAM isn't a lot of money. It's about as much as a date to the movies and cheaper than going out to dinner with the family.
edit: tense clarification
We could focus on musl support in order to get true static linking, but there are much higher priority things like 1.0 stability, optimizations, and compiler performance (though we'd take a patch of course). The fact is that pure static linking is rarely done anymore, at least on mainstream desktop/mobile/server systems, so it's not on anybody's critical path.
Dynamically linking to glibc does not really provide "better compile-time optimizations". LLVM already understands the libc functions that really benefit from inlining, like memcpy.