cargo-inspect does require nightly, though from a brief inspection it doesn't actually use rustc APIs like Clippy does. All it does is run rustc as an external command with -Z unpretty=hir or another -Z unpretty option, then perform some text processing on the result (diffing and syntax highlighting). It requires nightly because -Z options aren't available on stable.
A third-party tool can't directly access a stable compiler's APIs like clippy can, because they are gated on #![feature(rustc_private)] (which Clippy uses).
Well, it can access them if you set RUSTC_BOOTSTRAP. Or the documentation could ask users to build with stable but lint with nightly.
Perhaps those options are good enough. Honestly, they both sound decent to me. But the same options existed for Clippy itself before it started being distributed with rustup. The standard advice was, "If you're worried about nightly being unstable, it's still fine to use it for Clippy, since you're only running that locally. You can still use stable to generate the binary you actually ship." But for whatever reasons, users didn't like those options, and there was much celebration when Clippy was finally available on stable.
One of those reasons, especially for less experienced Rust users, was simply the stigma of using nightly at all. That said, I suppose there were also concrete usability issues which Clippy could have solved another way (and which an alternate linter could solve another way). To quote the announcement of clippy being added as a rustup component:
No more nightly updates that break clippy. No more manually
cargo install clippy.
Breakage from nightly updates would be less of a concern for a tool that only had a few lints. On the other hand, it might be more practical for the tool to be a fork of Clippy with added lints. It's already annoying to compile code twice, once with rustc and once with clippy-driver (which is why I don't use it). Three times would be worse, so it would be better to combine Clippy's lints and the extra lints. If the tool were a fork of Clippy, though, it would probably have similar issues with frequent breakage. But I can imagine ways to avoid this, like pinning to specific nightly versions and having a custom install script that used rustup to grab the correct nightly before doing the equivalent of cargo install. Or the lint tool could just distribute its own binaries, some way or other.
As for cargo install, well, it is painful to deal with, but that's a much broader issue that affects a large number of tools, so I suppose I can't complain too much.
Overall, overcoming those issues without rustup sounds feasible but difficult, requiring significant commitment to create a new linter. (Which, again, I'm not interested in actually doing; I'm only speaking hypothetically.) It would still have either the stigma of nightly or the stigma of using RUST_BOOTSTRAP, but maybe that's not the end of the world.
In short, upon reflection, my point about Clippy being in a unique position may have exaggerated the truth. But I do believe that it's true to some extent.