How is "client certificates forbidden" in any way an improvement?
I'm curious what other use cases there have been for domain-validated client certs aside from XMPP.
No it's not. It's a specific argument, that's true only in specific cases. You shouldn't handle knives, is equally a good rule from a general design standpoint. But nonsensical when you're a chef.
You should have separate chains is a reasonable decision when the ability to rotate out a compromised chain, and insulate some downtime, from other chains/usages is desirable. Needing to manage multiple cert chains is more overhead. Making use or maintenance harder. It increases complexity.
Large companies have never been afraid of more overhead. It's their singular advantage.
Removing features someone is using, and calling it better security, when it doesn't actually meaningfully reduce or remove some risk is weaponized incompetence. And sufficiently advanced incompetence, is....
There's no world where anyone gains additional protection, from a 3rd party compromise. Or one where LE has one of chains compromised, but doesn't rotate all of them.
It's one of those things that has just piggybacked on top of WebPKI and things just piggybacking is a bad idea. There have been multiple cases in the past where this has caused a lot of pain for making meaningful improvements (some of those have been mentioned elsewhere in this thread).
The PKI system was designed independently of the web and the web used to be one usecase of it. You're kind of turning that around here.
You're trying to make it sound like there has ever been some kind of an universal PKI that can be used for everything and without any issues.
"WebPKI" is the term used to refer to the PKI used by the web, with root stores managed by the browsers. Let's Encrypt is a WebPKI CA.
WebPKI is the name of a specific PKI system, where PKI us a generic term for any PKI.