Not just garbage collection but also the way hardware work is done with languages that allow you to write one-to-one memory representations in order to be able to drive raw interfaces of hardware. A GC language almost always comes with a reference based type system that hides the very interfaces you'd like to access (fast) and adds deserialization overhead which has visible performance and battery life effects.

The other reason is C interoperation. All of the common systems rely on C. C is not just a programming language. Since 80s everybody designs systems on top of C. We ended up with OSes written in C that ship their tightly integrated C compiler that outputs binaries optimized for C's memory layout and primitives that the very same OS runs on silicon that's optimized to run C fast. C unfortunately became the meta-language of the low level APIs.

Go's interoperability with C is out of hell. Its green-thread scheduler doesn't play well with C. The foreign function interface is defined in the comments (!) of a source file and making CGo work on custom cross toolchains is full of hard to solve compiler errors.

Rust can operate at the same level as C easily and it has all the low level primitives. C interoperability is a core language function that's part of the syntax and standard library. It solves many gotchas of C without compromising speed.

The non-JVM code used in mentioned context will run in environments where yet another GC fighting the JVM GC isn't desired or have to be a shared library talking to existing JVM code. While you can use Go to build libraries with C calling convention, it's not the most supported use case and it shows in ergonomics. This also includes standard Go types and standard library which don't fit nicely into a model where code needs to talk a lot with JVM world.

It's possible... But it feels like screwing screws with a knife. It's doable, but noone from the language designers, stl designers and library developers are really thinking about that use case.

Rust on the other hand fits very well into the model where it needs to be just a piece of a bigger whole - it's been built that way ("system" programming language) and it doesn't come with GC that will fight with JVM or Binder lifetimes, compatible type system and plenty of libraries that help develop libraries on an embedded platform. When building the language, Rust designers consider this as one of the main use cases of the language and it shows with how much less hassle it is to work with.

The fact that it easily fits into existing C/C++ codebases helps too.

Binary size, for one. The blog mentions a binary file grew from 220kb (C) to over 400kb (Rust).

I also doubt a garbage-collected language work very well for drivers that require precise timing (MMIO) and/or control over memory allocation.

Go is garage collected