Lots of rarer or older architectures are not in LLVM e.g. alpha, ia64, HP-PA. The LLVM backends which do exist for such also tend to have been exercised less and thus me more buggy (I think PPC/spe had a fair amount of issues there but it might have gotten better).
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.
Some of those older architectures are supported by the Linux kernel, which is adopting Rust. Giving GCC the ability to compile Rust code maintains support for those platforms as the percentage of Rust in the kernel grows.
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.
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.