The difference is not "testing" in a broad sense, the difference is "tests guaranteed to pass" vs "tests may run if they exist but we don't gate on them passing."

Being able to guarantee that they pass means having the expertise to fix any issues, and with a timeliness to be able to fix them and not block a release. That requires people around to support the target, with a higher burden than tier 2.

(Technically, it's even more than "not block a release" it's "not block any PR that may start failing on that target," since all tests must pass before a PR is landed.)

Commits don't reach master until they have passed all the test suites. As such, it is very burdensome to add more test suites: it increases the time taken to run the test suite and reduces the throughput of all rust development. Not to mention, many of the tier 2 or lower targets are not easy to run in CI.

You could ask: why aren't the tier 2 tests just run before release? But then, if they are broken it may be a significant amount of work to fix, and could delay the release.

Maybe there is a middle-ground where tier 2 tests are run daily, but then you need a team of people just to fix those tests, because it will no longer be on the original PR author to make sure those tests pass before their PR is merged.

An important factor here is hardware access. Tier 2 targets just produce cross-compilation artifacts, tier 1 targets require actual hardware to run on. For example, a tier 1 macos aarch64 target is impossible until the hardware can be run in CI, for every merge.

Tier2 compiler can be built with a cross-compiler, perhaps, but you don’t have consistent access to hardware to run the tests on. Just a guess

CI is expensive, even more on those targets.

I think it’s that the tests aren’t run, and consequently, they don’t guarantee the tests pass, which means it might not behave exactly the same as a tier 1 platform. So the difference is bigger than just tests.