Why does that matter?
It leads to lock-ins, like the current kernel is locked into GCC. Some of those GCC Extensions used are effectively proprietary because "the code is the documentation" so nobody can replicate it for their own compiler.
I do not believe that is healthy.
But only supporting one compiler has the advantage that you're aren't limited to the lowest common denominator of compiler features.
You'll notice this especially with C++ codebases which try to support GCC, Clang, Intel and Visual C++. You'll need a lot of macros and workarounds for each compiler's quirks.
C can be a hard to wrangle beast and the more checks I have on my code quality the better I sleep at night.
* Compiling SPIR-V shaders to GPU executables
* Compiling C
* Compiling C++
* Compiling Rust
* Compiling Haskell
* Compiling Swift
* JIT compilers for databases
* JVM JIT
Effectively once you translate to LLVM-IR you are basically home free, the LLVM can handle the rest. Which means you have a board range of people providing optimization passes, and catching bugs.
---
With the GCC its IR is tightly coupled to the C front end. While there has been some decoupling, this is generally considered a feature as it doesn't allow for a corporation to _run away_ with part of the project.
---
The LLVM is more modular, you can pick and take what you need. You can embed it, or call it externally. It is a hybrid BST/MIT/X11 license so it is open source, and embedding it in your project doesn't mean your project becomes GPL'd.