I recommend against attempting to use the root CA public key hash as a stable fire and forget TLSA record. Even the root CA used by Let's Encrypt will eventually change, and you yourself might stop using Let's Encrypt, ...
The less often you practice something that eventually needs to be done, and the longer you put off planning for it, the more poorly you end up doing it.
The folks who use 1 year certificates tend to have more issues with their TLSA records than those roll them often, but implement solid automation (e.g. https://mailinabox.org/, which for the vast majority of users just works). The one thing that some users that rely on automation miss is the need for monitoring. Unmonitored security is IMNSHO an oxymoron.
So to the question of what is best practice. It is indeed "3 1 1 + 3 1 1", where you configure Let's Encrypt to not change your key during regular certificate renewals (set reuse_key = true in the renewal .conf file), and arrange to inject a new key for certbot to use, only after that key's hash has been been published in DNS for at least a few TTLs in advance.
That way, if you forget to update the TLSA records, the certificate renewal process just keeps using the same key that already works, you keep obtaining new certs (for all those non-DANE clients to verify), and everything just works...
The tricky part is convincing your ACME client to switch to a new key when that key is ready. With certbot, this is not easy, and I expect to release danebot one of these days (I hope before long), that addresses the gap for certbot. With other ACME clients, that could be easier to accomplish.
It would sure be great if the certbot maintainers reached out and made available a command-line option to specify an override next key while renewing with reuse-key = true. With that, danebot wouln't have to jump through hoops wrapping certbot renew. Even better would be the ability to configure a one-time override key, just for the next successful renewal. Please ask the maintainers to step forward.
The other way to use "3 1 1 + 3 1 1" is to let certbot keep replacing the key on you, but not use /etc/letsencrypt/live/.../ directly. Rather copy the chain and key from there to an application-specific area, after ensuring that they are ready to use (e.g. match published TLSA records). Here you have some risk that if the DNS update fails to go through long enough, your current cert will expire and some non-DANE clients could be less happy. Again, monitoring is always important.
If you're willing to stay on top of LE's issuer CA change announcements, and accept the risk of LE issuing certs for your domain to someone else (because MiTM between CA and your domain, and weak ACME proofs, ...) then you can use "2 1 1" records, as some do (and some do poorly). See, for example, my notes. Some 82 MX hosts still list the retired X3 CA as a DANE-TA(2) (RFC7218 terminology), trust anchor.
--
Viktor.