Different use cases. You don't necessarily want a 10 ton standard library for every use case, like on embedded devices or plugins for a software package. C/C++/Rust being 1st class citizens is also very useful.
Standard libraries are what make languages useable. In my experience there's a solid case to be made for a 10-ton standard library (for targets with an operating system) or basically none whatsoever (for embedded). A thin standard library is always going to be too small to do useful things easily at the high level and too big to be deployed on an embedded system. Rust is good because it can play in both sandboxes.
For embedded devices you'd always be better just compiling C/C++/Rust directly to the native code. You don't have any portability possibility there in the first place anyway, so why ship inferior code gen with arbitrary restrictions?
Because you want to be able to dynamically load semi-trusted code on a microcontroller without MMU and run it without having to worry it could crash the whole thing?
Do you have an actual example of such a thing? I'm struggling to come up with a case of multiple independent mini-programs in such a microcontroller that needs, or even benefits, from that level of fault isolation.
Rapid prototyping, replacement for a scripting facility, diagnostics filtering & output, a platform for "apps" for a small IoT type devices and just the ability to run the same plugin anywhere you please.
It can be an enabler for new innovations. Even if it runs 2-10x slower than native code.
And what if the answer was just: just because I can? That's how a lot in our industry got started.
.NET's '10 tonne' standard library is a decent part of what makes it so usable. And it's not exactly massive either - I can publish a standalone .NET Core app that's only around 30MB in size. For the usability and GC, I'll take that over C any day.
That will probably come done quiet a bit when illink gets out of alpha. It is basically a tree-shaker to eliminate dead/unused stuff from the resulting standalone binary.
A tree shaking linker will definitely help a lot, but there's still some runtime baggage that probably can't be removed. For instance, dynamic loading and all of the related type and assembly metadata structures. I look forward to seeing what they can do!