The attestation system seems like it's reproducing one of GPG's UX problems: you have these categories of attestation, and it's seemingly pretty sane as long as everyone uses the attestations right (and there are enough players in the ecosystem doing the work of attesting). GPG's trust levels have the same idea, but in reality people often just pull keys from some public keyserver and then assign them Full trust.
I also think the true meaning of attestations is a bit murky. The `spot-check` and `code-review` attestations are about source code, `reproduced` is about the build artifact, and `sec-audit` is somewhere in the middle (ideally both). But it seems like these attestations are always attached to artifacts, not source code? So spot-check and code-review are really only relevant if the build is reproducible (and has been attested as such), right? Since that's rarely-if-ever going to be the case in the real world, it seems like another reason the attestation system will likely be misused in practice.
Finally, although I in-theory admire the goal of allowing the user to define their own policy about trusting updates (defining how many attestations of which types are required/sufficient), my experience in software update systems tells me that real people absolutely won't do this. What will happen, if Gossamer sees good adoption, is that (1) there will be a standard trust config that gets distributed and reproduced, (2) everyone will use that config, and (3) it will be very permissive, because users don't want updates to be delayed/denied. The authors seem to envision a world where there is an ecosystem of independent security vendors out there doing reviews and publishing attestations, but don't really provide any compelling reason why that world will spring into existence.