That's 02:01:15 PM (UTC), but you're correct.
My guess is that Let's Encrypt will transition straight from DST Root CA X3 to the existing ISRG Root X1 root in 2021. If that's the case, the replacement already has been issued.
For IdenTrust's own purposes, they have other roots expiring in 2034. I imagine they have their own plans to transition their customers, and the money to buy cross-certificates or other roots if necessary.
If Let's Encrypt has other plans, maybe one of the staff will chime in in this thread. 
That would be bad. 
Doubtful. If IdenTrust were so badly compromised that an emergency distrust was necessary, they would probably be in no position to have new roots trusted. If some sort of unusual situation resulted in only partial distrust, they might try to switch to one of their other trusted roots ASAP.
To call it "disruptive" would be an understatement.
Roots can't be revoked in the traditional way. Intermediate certificates can be, but roots can only be distrusted via a software update or other mechanism.
Google and Mozilla have other revocation mechanisms -- CRLSets and OneCRL, respectively -- which have and would be used to distrust intermediates when necessary, but I'm unsure if they support revoking root certificates. I imagine Mozilla could push out a hotfix extension, and Google could push out a software update or something else.
Consider the examples of DigiNotar, StartCom and Wosign, and Symantec. One is a small CA that was catastrophically compromised and widely distrusted immediately, leading to significant disruption to many people in the Netherlands and fewer people elsewhere. The others are larger CAs -- too big to fail, if you want to make that accusation -- that had different issues, leading to lengthy investigations and distrust over lengthy transitions period.
Well, since you control root distrust for your platform, the good news is you could keep using a compromised root forever. The bad news is you could keep using a compromised root forever.
Intermediate revocation via CRL or OCSP would be an issue for you -- if you implement it -- but could also lead to the affected CA rapidly switching to a different intermediate with less extreme disruption. (Let's Encrypt maintains a backup intermediate at their secondary data center, for example.)
Consider the recent case of the Logitech Harmony Link. They're bricking thousands or millions of devices in March. Rumor has it Logitech may have backed themselves into a corner with the upcoming Symantec distrust.
It's certainly important and good that you're considering these issues! 
I don't know what best practices are. Maybe you should trust several major CAs -- or all of them -- and one or two backup CAs generated by your own organization and kept in safes in case of emergency. I don't know if that's good advice, but as long as you trust a few CAs and have a functional software update mechanism, things ought to work out.
The best options might be to run your own CAs, or even have a backup software update system that doesn't use certificates at all.