For another example of this, see MIRI says `reverse` is UB, so replace it with something LLVM can vectorize by scottmcm · Pull Request #90821 · rust-lang/rust · GitHub
If you're editing two mutable slices, without this aliasing information then LLVM has to assume they might overlap (like they could if you're using (T*, size_t) in C++), and then it needs to very carefully preserve the exact order of writes and reads, since one of the reads might actually be reading something that was written by an earlier write.
You can see the impact of this by asking nightly rust to compile with and without this information: https://rust.godbolt.org/z/orzWWW4Wr. Ignoring the panicking paths and constants at the end, without the aliasing there's about 50% more assembly. Why? If I'm reading it right, it's because LLVM is being clever and actually emitting two different implementations, with a runtime check for overlap to decide which to use: the slow do-things-in-exactly-the-code-order-one-by-one version for overlapping slices, and a nice fast vectorized version for when things overlap. But thanks to Rust's rules about &mut, when compiled normally it can just go straight to the fast one, and not waste extra space in your binary on an unneeded slow path.