Why would browser compatibility change? The thing I mentioned about multiple issuer certificates was specifically for this point: The current cross-signing intermediate (as in: any intermediate leading up to the DST root, not this specific instance of a cert) is going to be around for a long time, it'll take years till ISRG is recognised by the majority of users. Sure, there might be a key rollover, additional issuer certs could be added, but that does not break anything as long as you implement ACME correctly and follow best practices. I would also expect there to be a lot of compatibility testing in case any of the X509 fields are changed for future issuer certificates after seeing how XP was initially affected by a subtle bug triggered by the X1/X2 certificates, with the baseline being the currently supported devices. This part of the Integration Guide would apply here, I think, in case there are any backwards-incompatible changes:
To make a reference back to "traditional" CAs, it turns out Let's Encrypt wasn't the first CA to trigger the IIS bug that caused issues during the X1 -> X3 migration (there are some old Stack Overflow questions on this topic, I believe one of the affected CAs was StartCom). Even traditional CAs don't typically guarantee which intermediate certificate is going to be used, and you're not safe from subtle bugs like that one. There's a good chance an issue like that (where the correct intermediate certificate is missing) wouldn't have been noticed during testing even for manual certificate deployments as those are cached by browsers and there's a good chance you'd have visited a site with that intermediate before ... so would you really be off any better with a manual system (not that you're making that argument, but in an attempt to weigh the risk you're mentioning)? 