I think this would both demonise unsafe code beyond what is reasonable and give a false sense of security. While I agree that evaluating the quality-level of a program including its dependencies is a good goal, I think focussing on unsafety as a way to do so is somewhat naive. I would prefer to rely on social solutions such as audits (e.g., the libs blitz, or some security focussed variant) and formal approaches such as the rust belt work.
I believe that the majority of unsafe code is not a problem - it is small, self-contained, and innocuous. I further believe that in general leaf crate authors are not going to be able to judge the safety of such code, i.e., whether such code is trusted. Furthermore, they have to trust not only that the use of unsafe code is safe today, but that it will remain safe for evermore (unless they check every transitive dependency every time it is updated).
Next, unsafe code is not the only source of bugs. If you care so much about safety/quality that you would check every dependent crate for unsafe code, you should almost certainly be checking them all for logic bugs too. This will make that more unlikely by giving a false sense of security that the code is safe if it passes these checks.
To put this another way, while this sounds superficially useful, I believe that it will encourage over-cautiousness where it is not warranted, and where caution is warranted this only makes a minor improvement (and possibly discourages best practices). This is security theatre.