What are the practical implications of this? Could cargo call GCC? Or would it be like gcj and allow compiled rust libraries & binaries to be distributed? (at least in theory, gcj didn't work out well)
Unless you mean some specific chips?
The latest xtensa-esp8266-elf-gcc is version 5.2
You can see something of a summary over on https://builds.Debian.org/status/package.php?p=rustc&suite=s... the BD-Uninstallable entries are unsupported archs, though some of them might be due to rustc or bringup bugs (e.g. m68k is supposedly supported by llvm and rustc).
Then there’s embedded, on the more open side LLVM is slowly gaining ground but there’s also less open ecosystems where customising / forking gcc is pretty standard historically, and there’s not much LLVM can do.
If there are people who care about these historical architectures, they can do the work to maintain them in LLVM. That's how m68k support was added.
Or they can decide to use an existing compiler that already works.
There are also embedded applications, of course; plenty of crappy manufacturers still give you a GCC fork as your only compiler for their dedicated hardware. The ability to get Rust hooked into those compilers can help keep the ecosystem up to date.
Even companies maintaining their own software sometimes take a long time to add support to LLVM. Take for example Espressif's Xtensa fork that is only now starting to get merged (if https://discourse.llvm.org/t/rfc-request-for-upstream-tensil... is to be believed). Many patches are still waiting for review, so it'll be a while until LLVM finally supports Xtensa (and with it microcontrollers such as the ESP32). GCC has had Xtensa support for ages (Github lists xtensa.h going back all the way to 2002) and I doubt Espressif is the only company in this position.
"Just do the work" sounds easy but that work can take years. Getting modern Linux versions to compile may not be enough to drive companies to put in the effort; many may prefer to simply never update their kernels past the current LTS version again.
Adding a frontend to GCC works around this problem quite efficiently. It also makes it easier to port existing code to these platforms; sure, the lack of a borrow checker drops all guarantees Rust has been designed to provide, but if you're not writing any code, you don't need those anyway.
Non-standard C-like languages are used in computer graphics and GPU computing (OpenGL, Direct3D, OpenCL), but strictly speaking they don't count as C.
It was kept around for a long time after everyone went to OpenJDK, because it was the only project with certain unit tests for GCC code paths, when that was eventually sorted out, it was when they dropped it.