Yeah, I certainly recognize that the good people at Let's Encrypt understand the complexities of the CAB/Root requirements, the WebPKI in general, and their own platform specifically all much better than I do. I just would have naively thought the prior behavior was everything behaving as expected and documented, even in the revoking-for-keyCompromise-by-only-proving-domain-ownership cases (like, we recommended it as the best way to do things here just a couple weeks ago), so the fact that the behavior was actually considered a bug (and not just any bug, one that needed to be embargoed for 8 weeks for other platforms to be able to "patch") has really just thrown me for a loop.
If this new way really is The Right Way to do things, though, then I think the next step is really getting a lot more details and recommendations into the documentation, especially in the Integration Guide and ACME Implementation Details, as well as making sure ACME clients update their behavior. Like, the revoking documentation says that Certbot will use the account key by default, which I'm guessing means that if you add --reason keyCompromise it just won't work unless you also add the --key-path parameter? I would guess that it should be smarter about picking which key to sign the request with based on the revocation reason now.
I guess the other main thing I'm trying to say is that if revoking for key compromise becomes harder, then people may be more likely to just not report it at all instead, or revoke it for some other reason leading to it not ending up on the blocked-key-list even when it should, so it's in everyone's best interest to ensure that key compromise revocation is easy enough to be able to actually happen when it's needed.