If your feature use policy is that you will
never use any feature unless it's supported in at least X, Y, and Z browsers, then yes something like this would be possible. But most sites don't have a policy like that.
Most sites are willing to use some features as a progressive enhancement, whereas other features they won't even consider using unless it's in 99+% of their users' browsers.
And unfortunately there's no easy way to make that decision for users on a feature-by-feature basis, because it all depends on what use case they're trying to accomplish, and what will happen if the feature is not available (given that particular use case).
So our approach is to (1) explain in the guide how to implement the use case with the modern feature, (2) explain why the modern feature is the preferred solution (e.g. what the user benefit is), and then (3) explain how to implement a fallback solution if the feature is not available.
I think we could potentially experiment with some version of what you're describing, like a config option where we only surface guides that have robust, widely-available fallbacks, and where we have high confidence that it makes sense for the majority of sites to be following the recommendations in the guide.
I'll raise it with the team.