Oh, sure. I keep counting down the years, and know that starting in 10 years or so when everybody really needs to start moving off of ISRG Root X1 it's going to be a bit chaotic around here. For my use case, where it's just my personal domain I think I can track things enough to know that I'll need to update things when the root changes, but I can see how it might not be the thing that one wants to recommend to people in general.
This domain doesn't seem to exist, and I'm not familiar with it. Is there a typo there or something?
If you have automation for updating the DNS records, what's the advantage to keeping the same key for some renewals?
I'm not using Certbot, but a cobbled together custom solution (because I like making things harder on myself, I guess), but I think that if I were to implement 3 1 1 I'd just automate putting the new key in once I get my certificate and wait a day before having the mail server actually use it. It'd be a fun project and probably give me a chance to play around with AWS Step Functions which I've been meaning to do. So I'll probably go that route eventually. It just seemed like it'd be a lot easier (and would help with adoption of SMTP DANE in general) to try to re-use the public web PKI that's already in place as much as possible. Like there should just be an easy way to say "Only connect to my mail server via TLS" and using the regular trust mechanisms that everything else does. MTA-STS (which I'd already implemented, even more DNSSEC) of course does just that, but it seems overly complicated (setting up an HTTPS server just to say that your SMTP should be secure) for what could just be a random flag in DNS saying "security is supported". Honestly, a domain using DNSSEC in and of itself should probably be enough of a hint that the domain is maintained well enough that one shouldn't send it anything unencrypted. 
Well, if they haven't noticed by now then they must not actually care about getting mail.
Are you, like, crawling the entire DNS tree regularly to scan for MX records and measuring how many have valid DANE setups?
Definitely agreed there. I think that this is something that the ease-of-use of certbot may be hiding from people, where it seems a lot of people have systems that they aren't keeping an eye on.
Thank you very much, both @ietf-dane & @Nummer378, for your helpful thoughts!