Why is `RUSTC_BOOTSTRAP` so actively discouraged?
For a library RUSTC_BOOTSTRAP is a really bad idea. If effectively forces all your consumers to risk being broken with any new rust release. Builds of Firefox broke once because one of their dependencies used RUSTC_BOOTSTRAP internally. After that incident Cargo got changed to not allow individual crates to opt in to RUSTC_BOOTSTRAP and instead force the person invoking cargo to pass it and thereby acknowledge that the project may break with rustc updated. Also if some library deep down uses RUSTC_BOOTSTRAP then it may be very hard to ensure this library gets updated. The library may not do a timely release (for example because it is not actively maintained) or it may do a new release, but the new release is not semver compatible with the version that your project uses. In both cases you are effectively forced to vendor and patch the library. Also the library update may (have to) break compatibility with the MSRV of the project. And finally if the library only updates for breaking changes to unstable features whenever a new stable version gets released, that makes it effectively unusable on nightly and beta, preventing your users from finding bugs in rustc before it is already too late.
For an end project, these risks are less bad and there are some major projects that use it (Rust for Linux (RfL), Chromium, ...), but still we prefer if people don't do this. In the case of RfL we are actively collaborating on unstable features they need to get them to a stabilizeable state. And for RfL we have a CI job on the rust side that allows us to notify the RfL maintainers about the impending breaking change such that they can adapt to the changes quickly.
Discussion in the ATmosphere