Hi @ltamm! These are excellent questions. 
The broad concern with long-lived certificates is that the longer they’re in use, the more opportunity an evildoer has to steal them. (This is often expressed as the axiom that the longer a key is in use, the more valuable it becomes.) Also note that you will usually not know when a compromise happens. You might know when it’s exploited, but then again you might not – this is another way in which minimizing the opportunity is important.
In concrete terms, once an evildoer has a certificate’s private key, they can assume the identity of the entity that owns the certificate. So, for example, if they steal a trust anchor’s private key, they can generate their own identity issuer certificate, rotate that in, and then do pretty much whatever they like with Linkerd’s mTLS: they could take over workloads, eavesdrop on mTLS communication, etc. (though they could not decrypt communications from before the certificate swap happened).
This sort of maliciousness generally does require access to the cluster, but not the Node. (If you have privileged access to the Node, you can do much worse things. 
)
I’m not personally aware of operational issues with cert-manager’s renewals for the identity issuer. For the trust anchor, you’ll ideally go in after you know that nothing is using the old trust anchor and remove its public key from the bundle. The major operational issue I know of for very short-lived certs is that linkerd check will complain if the expiry period for the identity issuer or trust anchor is less than 60 days.
Hope that helps!!