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 exactly like global state.

Rust is comfortable with immutable statics. The existence of a global readable Doodad is no problem. For mutable access static Doodad Rust requires unsafe, because you will probably shoot yourself in the foot.

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<NetworkIF> 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.

As in all things--sometimes.

One thing in particular that is gratuitously difficult in Rust is to do some very expensive runtime initialization, place the result into static memory, and then do read-only things to that memory after it is initialized.

Rust really does not like that pattern (it always wants you wrap that and takes locks to it with the associated performance hit) and yet it is an extremely common thing to need to do (embedded communication stacks, graphics card shaders, etc.).

global state is often necessary. Abusing it is always possible, but every startup-sized application footprint I've ever been in we eventually have to add an exception to the no-globals linting rule for some very legitimate reason in some specific place.

The crate ecosystem (oncecell, lazystatic) lets you completely sidestep this limitation for now anyway before better const behavior eventually gets added to stable