* Expiration times and GPG-level revocation must be ignored (for
time-travel, and pulling from an old Guix), similarly to why it must
be ignored for when no subkeys are used
     * Someone used to GPG-style subkeys generates a new subkey to
replace old expired subkey or revokes old subkey, without keeping in
mind that Guix doesn't take that in account.
     * An attacker uses a compromised-but-revoked-or-expired subkey to
compromise the channel.

Why does none of this apply to primary keys?

For primary keys as they are currently used in Guix, to revoke a key (from Guix' point of view), you remove it from .guix-authorizations, done.

For revoking subkeys, you trust GPG or whatever to take care of things, but Guix-modified-to-allow-subkeys-too doesn't have a clue that the subkey should be considered revoked, se bullet list above.

That could be solved by also adding a list of revoked subkeys to .guix-authorization, but that seems opposite to the proposed change.

Expiration times might be solvable by taking the commit time of the
previous commit as 'current time' (not the commit that was signed,
otherwise an attacker could just lie). I don't know a solution for
GPG-level revocation of old subkeys but I haven't looked either.

Git commit dates aren't reliable.  Requiring that they be accurate going forward would be imposing yet another 'artificial'/idiosyncratic limitation.  I think we should be very hesitant to build a verification system on assumptions stacked just so.

They do not have to be accurate however, as long as the discrepancies in commit dates / actual time (*) are small compared to the expiration times.

(*) of non-attackers -- assuming frequent commits, an attacker cannot trick the expiration mechanism into large time difference.  That might not be good enough for branches like 'wip-foo' or channels with infrequent commits though.