And yet the existence of this exploit, which would have been prevented with HTTPS as I understand, counterproves your point. There's a reason security engineers advocate for defense in depth; even if one system fails you have a higher likelihood of preventing any issue or perhaps at least mitigating the scope/severity because other systems are still there. Self-signed HTTPS certs seems about as safe & secure as self-signed PGP packages so how can having both in any way reduce the overall security.

I would again add that preventing a connection from forming, preventing protocol, buffer, filesystem, and timing attacks as well as preventing a malicious payload from ever reaching disk, is itself a great improvement. Also it carries the guarantee that once the transport is finished the contents are ready to be trusted rather than the transport -> validate -> trust model using PGP signatures.

For maximum security and user experience I'd say both though - validate you are connecting to who you think you are and also validate the PGP signature. For how often packages are installed vs how high of a risk remote code poses to the system I think it's a bit foolish to say we can only do one and when we do we are perfect.