Please judge for yourself whether it was appropriate to block CI on these diffs:
I agree that this was annoying. Happily, the rest of the CI checks are no longer blocked on tidy, so you shouldn't have this issue in the future.
However, I was not prepared for the rust repo's tidy check.
I think for new users, this shouldn't be so much of a problem. It's mentioned explicitly in the contribution guide, for instance. x.py test tidy is very quick in my experience. (Note that passing tidy was always a requirement for rustc — the checks have just become more stringent with the rustfmt requirements.) In addition, the change above should make things less frustrating in this regard.
(In my opinion this last one has actively made the code much worse!)
Forcing rustfmt in rustc has been somewhat a point of contention recently — there's a long thread on the merits and demerits of enforcing rustfmt in the Rust repository in Forced rustfmt is a roadblock to contributing, which you might want to skim through.
I agree with @josh that the one-time cost for setting up the repository gives the contribution experience more overhead the first time: after this, the experience is much faster.
However it's also not clear to me why tidy requires a bootstrapped compiler to run, perhaps that could be changed.
You don't need to compile rustc to use tidy, just the tool itself. I think you should be able to use rustfmt (with the same settings) to essentially reproduce tidy, modulo some features like checking error numbers.