Honestly, it's not. For several reasons.
First is that dealing with allocation failures is a niche concern. That doesn't mean it's unimportant, but it's niche. I've been writing Rust for a long time and I've never wanted anything other than "abort on OOM" semantics. There's a whole world out there for which the current behavior in std is just fine.
Second is that aborting on allocation failure is a property of the standard library, not the language. This is why Linux kernel development is able to use Rust: they don't have to use the
alloc crate. They can build their own. That's what they're doing.
Third is that in many common scenarios (such as on many Linux distros), overcommit is enabled. This means that you're unlikely to ever even get an allocation failure. Instead, your process just aborts at the time of a memory write and there is likely nothing you can (or will) do about it unless you change your overcommit settings.
Plenty of old and existing systems tooling (like, for example, grep) will just abort when it can't allocate memory. I don't recall ever hearing anyone complain about that kind of behavior. There are for sure certain scenarios in said tooling where detecting allocation failure is a useful technique, but it's not the norm. And that's one of the reasons why folks are working on bringing fallible APIs to std.
You might consider that others have different definitions of what "memory-safe" means. Aborting on a failed allocation is not something that Rust (nor anyone I know) considers memory unsafe.
No, there is no plan to change this because the only choice for removing the panic is a silent failure, and I (as a member of the libs-api team) would consider that a pretty serious breaking change. (For example, it would turn programs today that abort when the stdout pipe is closed into programs that might never abort.) And the panicking behavior of
println! is documented. If we could do it over, I might advocate for something different, but that ship has sailed IMO.