BuildStream & co do have features to cache failed builds for example, and my experience with those tools is that it causes quite a few headaches (especially for bazel, since it lacks the force rebuild switch).
Most of the time I know that my build failed when working locally, and only re-run it to check if the failure is spurious, so the use case is almost nonexistent locally (though it does provide a quick way to check whether my derivation changed meaningfully, and can speed up tests).
The issue comes in when building stuff that has been cached to fail remotely, which seems to be the main use case intended here - it in effect poisons the cache, because it makes it so that CI refuses to ever try again, which is very problematic (occasional successful artifacts from a broken build is better than no artifacts ever). Users can’t determine whether the remote build failure is spurious either, and either know about this quirk and force rebuilds anyway or end up confused. If the “spurious build failure” story isn’t thought out well in advance, it can be very annoying.
I like @SergeK’s suggestion, assuming it also means that non-interactive builds will always still rebuild. Giving a prompt also flags to a potential user who isn’t aware of this caching why the build is failing, though I’d like a more expressive message focused on new users.