To be honest, rather than magical blessed keys held by a few orgs, I'd feel more comfortable with a slightly larger number of individual reviewers (and prosaic keys), each with some kind of visible distance metric related to the codebase they're signing artifacts for.
For example: "ah yes, a core contributor, a frequent code reviewer, and two downstream consumers of this library have signed off on the changes in this release. even if one of them is having a distracted day/week, that's good enough for our team to be comfortable upgrading it today since it's a minor version upgrade"
Sure: I don't think any of this should go the way of TPM and EFI (magic primary keys held by those big enough to have legal departments for the committees) - but it's a short hand to acknowledge that almost everyone would mark "Google and Microsoft internal use approved" package keys as absolutely trusted and mostly not worry about it.
That seems like it'd be a way for those companies to attempt to capture the technical infrastructure used by packages, and hold their adoption potential hostage (soft pressure for packages to change their practices to become approvable, and latterly a hope that the wider community will tend to believe in and trust those approvals).
You could be correct, maybe this would work in practice, trading on the reputations of those companies. It doesn't feel particularly open or community-oriented, though. Why not present a trust graph built from a broad set of worldwide users instead?
(one of the benefits to a trust graph would be the volume of signers; perhaps you wouldn't want to weight each signing equally -- again referring back to something like the distance metric mentioned previously -- but for even mid-popularity packages, the detailed review possible by careful users of a package could, I expect, be more reliable than automated-and-manual review by one or two large companies)
For example: "ah yes, a core contributor, a frequent code reviewer, and two downstream consumers of this library have signed off on the changes in this release. even if one of them is having a distracted day/week, that's good enough for our team to be comfortable upgrading it today since it's a minor version upgrade"