I'd argue that anyone who thinks language safety is some authoritarian handcuff doesn't really understand low-level programming to begin with.
I think few people in this discussion are worrying about programs directly affecting other programs through memory unsafety, exactly because this doesn't really happen for software that isn't a driver or inside the OS kernel. The problem with memory unsafety is that it often allows exploits that corrupt or steal user data, or gain unauthorized access to a system. That's not a problem when you are the only user of your software and you only have access to your own data, but once you have other peoples data or run on other peoples system I think you should at least consider the advantages of using a safe(r) language.
Most "interesting" programs can perform I/O. Then you run into ambient authority and confused deputies.
Most programs do not need arbitrary access to the file system, and it should be the OS's job to whitelist which files a program has access to. Again, a safe language is not going to save you from bad behavior on the filesystem either. It really only solves the memory problem.
Except that it is often a memory-safety problem that enables an attacker to make a program misbehave, through things like buffer overflows. A memory-safe program is much harder to exploit.
Even with a safe language, there's vulnerabilities like supply chain attacks which allow malicious code to use an escape hatch to access memory outside of the process. I.e. I could be programming in Rust, but one of the crates I depend on could silently add an unsafe block which does nefarious things. OS/hardware level sandboxing could prevent many such classes of exploits.
The problem is not about memory outside of the sandbox, but inside. Please read about return-oriented programming, for example, where a buffer overflow bug of a process can be exploited to hijack said process to do work it was not meant to do normally. If this error happened for example in sudo, it can very well be used to gain privileges and do real harm — and this whole problem domain is almost entirely solved by using a “safe” language.
https://news.ycombinator.com/item?id=27642630
In short, memory unsafety makes programmer bugs exploitable, instead of generally just failing.
Let's say we have two programs, A and B.
Program A by its very nature needs to have write access to the system's file permissions in order to fulfill its core purpose.
Program B only needs R/W access to a sqlite database installed in a specific directory, and the ability to make network calls.
I would agree that for program A, a memory-safe language can provide a very real benefit, given the potential risk compromising this program could expose the system to.
Would you agree that if a buffer overflow exploit in Program B can be used to compromise the system outside of the required resources for that program, this is a failing of the OS and not the programming language?