Earlier quoted context omitted.
*> poor support for static/globals I'll agree with your other things, but discouraging global state is an aspect that reduces ultimate complexity, rather than increasing it. :P
It increases complexity if the state is intrinsically global. Hardware resources, for example, which are commonly directly managed in systems code, are intrinsically global state. You can't allocate another hard drive or physical network interface. I've seen impressively convoluted code that existed solely to pretend that global state isn't actually global state, because that was seen as bad, even though it behaved e…
Imagine there's a static NetworkIF nic which is immutable. Maybe we can call predicates like nic.up() to find out if this interface is up, or nic.packet_counts() to get some statistics about packets. But it's immutable, so we can't call nic.change_addr() or nic.disable_packet_filters() as those require mutation. If it was mutable we'd need unsafe Rust to try to call those, because doing so means being very careful about who does what and when they do it or we'll get in a mess.
Because of "interior mutability" we can have a Rust static which is immutable from a Rust point of view, and thus safe, but where we can get at mutable internals. For example static Mutex nic. Now it's protected by a mutex. We can lock the mutex, and thus get mutable access to the NetworkIF, until we release that lock. If somebody else has the lock then we'd block waiting for them to release it.
With just mutable globals everywhere and a larger team it's easy to end up with clashes where two subsystems both think they "own" a shared mutable object and treat it accordingly then are surprised that this doesn't consistently do what they expected.