It remains to be seen whether you can have a useful borrow checker on top of a simpler type system (at least, a type system that's significantly simpler so as to meaningfully reduce compile times). I have my doubts, personally.

The borrowchecker is not the source of the bulk of the language's slowness. It takes a fairly small fraction of the total time, I think I remember the number was 5%-15% depending on the project.

The majority of time is spent between the trait solver and LLVM optimization passes. There is work being done to improve the trait solver and to produce more efficient LLIR code from the get-go (so LLVM has less to optimize).

The Rust compiler, while not extremely fast, is not extremely slow either. As an example, my toy compiler is 130K LoC of Rust and compiles in under 7 seconds on a cold build on my M5 Max. An incremental build is nearly instant. So then why is it that so many projects have a minute compile time with far fewer LoC?

The answer: dependencies (My compiler has virtually none, intentionally)

Rust has a very small stdlib, so you are forced to bring in dependency crates, and not just a few. Many programs have 50-100 or more, and they all have dependencies, and so on. Contrast with Go where it has a culture of few dependencies, and those project have few dependencies. Your Rust compiler is doing a lot more work for what appears to be the same program as in other langs, but ultimately is a lot more code (typically).

To make matters worse, cargo does a decent job of parallelizing the builds, but it can only do so a) at the crate level b) only as much as the dependency graph allows.

   └── rand v0.10.3
    ├── chacha20 v0.10.2
    │   ├── cfg-if v1.0.5
    │   └── rand_core v0.10.1
    ├── getrandom v0.4.3
    │   ├── cfg-if v1.0.5
    │   ├── libc v0.2.191
    │   └── rand_core v0.10.1
    └── rand_core v0.10.1