I think the answer for many of your questions is "available resources", Mozilla has only limited resources for rust and while rust has a very nice community driving rust, it is a big difference to e.g. google which probably has more paid developers on the Bazel build system than Mozilla on the whole programming language...

So instead of choosing a large feature set at the beginning and the box it through, they choose to have a more thin
compiler, standard library etc. but make it extendable, so that it can be extended and integrate with other systems. Also you should not forget that Rust is still very young for a programming language so cargo is everything but done. Cargo is more a unified interface combining the compiler and the crates package repository than a full fledged build system. Given the available resources and time for building rust, I thing choosing to (for now) not include a fist class rust coverage system, debugger etc. is a sane choice, especially because all this things are available as external tools (debugger=gdb, coverage=kcov, etc.).

Also there are discussions/issues about enabling the integration with "enterprise" build systems, they just currently don't have a high priority and happen mostly in the background. So it's probably just a matter of time
until you can use rust with a "enterprise" build system
like Bazel.

Wrt. clippy integration in rust, it is mostly about keeping the compiler smaller and easier to maintain. Through it should be noted, that all "important" lints are in rustc, clippy just provides more useful ones. By keeping both projects separated it is possible to iterate both of them independent of the other. Which can be quite useful in open source development. Also don't enterprise systems also have a separate linter? (And no "better code" is not better code for every one, as the definition for what good code is can change quite a bit depending on the person, e.g. wrt. variable shadowing)

Lastly I don't think your reasoning about peers holds, you don't really have the choice to be selective about people working on the project, at last not if you have open source project on the scale of rust. Through you might be able to have more strict requirements for code quality. Nevertheless given how rustc catches a lot of possible bugs, and how to community is, I would be surprised if there would not be some less experienced programmers contributing to the compiler. But then at last Mozilla also uses rust in production, so some parts have deadlines and even if not it's quite different for them then a `A-game`classification. Also it's not so, that you can't have metrics about lines/branch coverage, failed the build on certain thresholds, etc. It's just not necessary a build-in feature, through available nevertheless. Also it would be really strange if a programming language / build tool would decide which amount of coverage is ok, it's something the project manager/programmer has to decide (once) and then configure the build tool to enforce it (I most likely did misunderstood you on the last line ;-) ).

Ups, I wrote much to much.

TL;TR:
1) rust has less (programmer) resources
2) it's still young, tools like cargo, or the testing API are everything but complete. Through they do there job good enough for now.