They didn't exist at the time. cargo was built using lessons learned from other package managers, however.
> Why is clippy, like Findbugs, separate from the compiler?
The compiler didn't want to bloat its lints. Being out of tree let us iterate quickly. It lets us work on extremely useful lints which as a side effect have false positives (there are a lot of patterns it catches which might be buggy but sometimes have legit use cases that are hard for clippy to detect and ignore). It lets us add controversial lints. In general a separation between the "core" lints (which everyone usually agrees on passing, and cover a small set of bare-minimum issues) and the clippy lints (which not everyone agrees on, and cover a wide range of issues which don't always apply to your codebase) is nice to have.
There are many reasons to not want to run clippy, one of them being that's it's too strict/annoying. In Servo we can't run clippy because someone needs to go through it and update Servo over the thousands of warnings clippy produces when run on Servo (many of which are false positives). I occasionally do some of this, but clippy grows pretty quickly too so each time I do it there are new things. (I'm waiting for rustfix to mature so that I can automate a lot of this).
So, to me, clippy should be something you have to decide to use.
We do plan to make clippy part of the rust distribution (bundled with cargo and friends), it's just not happened yet since it's blocked on a bunch of things.
Clippy not being part of the default pipeline is just an artifact of its immaturity. It's still used by a lot of people despite not getting free publicity from being a default which is promising, though.
I don't see why there's much value being assigned to "first class" tooling in Rust. code coverage and clippy are a `cargo install` away.
> Most of these are fresh college/code-bootcamp developers but there are some rare bad experienced developers
There are a LOT of new/inexperienced programmers in the Rust community. You're right that there's still some selection bias, but Rust tends to be pretty welcoming. I've mentored people who've only done very basic programming in making Servo pull requests. Some of the sporadic clippy contributors are pretty new to programming.
> Why would you need metrics about how many lines+branches of code are tested?
I have never seen opposition to code coverage in Rust in that form. In general folks in Rust are happy to have more kinds of checks lying around.
It's not part of the pipeline mostly because it's a cargo install away. If your project needs it, it's pretty easy to make it part of your workflow.
There is an argument to be made that making it part of the pipeline will mean that more people will be driven to use it, which is great. You'd have to take it up with the tools team and community if you think this is something that needs to happen; I am mostly ambivalent about the idea.