The borrow-checking and ownership mechanism is cheap, and it's almost never a significant part of the big compilation time encountered in Rust.

What's not cheap, and is responsible for long compilation times (the order is arbitrary, the relative weights are highly dependent of the code-base):

- size of the code generation units (the whole crate vs individual files in C)

- procedural macros

- generics & traits

- interaction between generics & LLVM IR generation (a lot of bloat is created, to be removed by LLVM later)

- LLVM itself

Most of those are being worked on, but in the end it's mostly a social problem: as Rust users are used to long compile time, many of them don't especially take care of it, and most gains in the compiler are often outweighed by people writing slower code. It's already possible to write Rust code that compiles quickly, if you pay attention. The culture is evolving though, and more and more library authors are now mindful of compilation time of their crate (and the tooling to diagnose it is also improving).

Key takeaway: Memory safety isn't what makes Rust compile slowly, “zero-cost abstractions” is.

Because a complex language is harder to read, and so slower to read and understand, and so to maintain over time without introducing bugs; compilation speed also slows you down, which means you write fewer tests. In general, getting a correct program requires effort. If that effort goes elsewhere, there's less of it for correctness.