I think I agree with this, though with a slightly different rationale.
We've been increasingly moving toward a model where the build/CI/release infrastructure is completely standardized: we run the same core process whether we're tryign to land a PR, producing a nightly, or producing a release. A big part of the motivation there was eliminating problems where PR tests would succeed, but production of a nightly would fail; that's literally impossible now, but used to be a very stressful and painful aspect of Rust maintenance.
@alexcrichton has often articulated the principle that if you don't test something, it will break. And our experience has been that trying to coordinate with breakage after the fact, and get "the next nightly" working, tends to cause a lot of pain for everyone. It also increases the risk that there will be breakage at the point that it's time to cut a release.
Yet another angle: we surely want stable releases to test these tools (given the elevated status we're trying to give them); if we don't also test on every PR, then we put ourselves back in a situation where CI differs between different kinds of builds/releases, which seems like a step backward.
TLDR, I think based on the lessons we've learned in the past about CI, on the whole it's going to be less overall pain to bake these tests in everywhere. The fact that this leads to higher quality nightlies is a nice side benefit.
Finally, regarding the burden on those contributing to the compiler: Servo has a somewhat similar problem, where a change to Servo could cause breakage in Gecko, which the contributor knows nothing about. I think a good strategy there is for the Clippy or rustfmt maintainers to offer to take the PR over the finish line, or at least to help mentor the contributor through fixing the problems in the case where it's nontrivial.