@SebastianOerding's answer is good, but I'll try a different explanation by building on the concept of a cross-certificate.
Let's say you have two separate CAs, and you want the clients of CA1 (ie those with CA1 in their trust stores) to trust certs issued by CA2. You want to do this without adding CA2 to their trust store.
The solution is a cross-certificate, from the Microsoft documentation:
Cross certification enables entities in one public key infrastructure (PKI) to trust entities in another PKI. ... A mutual trust relationship between two CAs requires that each CA issue a certificate to the other to establish the relationship in both directions. The path of trust is not hierarchal (neither of the governing CAs is subordinate to the other).
So each root issues a certificate containing the public key of the other (self-signed) root CA. This allows path validation engines to "pretend" that the self-signed root cert of CA2 was issued by the cross cert, which was issued by CA1.
Now, think of a link cert as a special case of a cross cert where CA1 and CA2 are two different root certs for the same CA (ie the same CA DN), but with different public keys (and likely also different expiration dates, serial number, CRL location, etc).
Root key expiry is a problem because as far as clients are concerned, it's a brand new CA. Link certs bridge that gap by telling clients that this new root cert replaces the expired one that is in their trust store.