Because then you are bound by the release schedule of GCC. Of course one can think about separate projects like the gcc-rust one where you can have whatever release schedule you want. But then it'd be a separate project building on GCC and not a part of the larger GCC project itself.

LLVM having a separate release schedule from rustc isn't a problem. rustc can miss out an LLVM release without problem. A rustc 1.35.0 compiled with LLVM 5 can compile a rustc 1.36.0 compiled with LLVM 7. However, GCC can't miss out releases. The rustc 1.36.0 frontend needs at least a 1.35.0 frontend to compile itself. And most Rust programs in the ecosystem work with rustcs compiled with older LLVM releases, but most Rust programs that have dependencies do need newer rustc releases.

As for stability of MIR: currently I think MIR is serialized to disk in a glorified mmap way. Basically following the Rust memory representation. It's great if both the creator of the MIR as well as the part that reads the MIR are written in Rust. Furthermore, there are libraries about how memory layout should look like that are provided to codegen backends. Those libraries are written in Rust and not really usable outside of Rust. So currently unless someone serializes MIR using e.g. bincode and provides C bindings for those layout libraries, there are good reasons to write the codegen backend in Rust itself, at least the part that translates MIR to the next stage.

In this fashion, LLVM IR is different as it allows a multitude of languages to communicate with it.