Yeah, how WebPKI works definitely has some differences to how the PGP Web of Trust infrastructure works. Actually, while falling asleep last night I realized that I had also forgotten a fourth method of requesting revocation, which while it kind of allows for this sort of thing is not something one should really build a "process" around. But I thought it might be instructive to explain it, just for completeness sake.
The official documentation of how Let's Encrypt works and what a Relying Party can actually Rely on is in two documents: A Certificate Policy (CP) and a Certification Practice Statement (CPS). [I'm not really sure why it's split amongst two documents, honestly, but it seems to be a part of how CAs work.] These documents are based on the Official Rules that all public Certificate Authorities need to follow as set out by the CA/Browser Forum. Specifically, for revocation, take a look at Let's Encrypt's CP §4.9.1.1 "Reasons for Revoking a Subscriber Certificate" and CPS §4.9.3 "Procedure for revocation request".
Based on those, you can see that anybody can provide "evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise" in order for Let's Encrypt to revoke that key, and that such a revocation request can "be made by emailing cert-prob-reports@letsencrypt.org".
So, here's what you do if you really need to have something like PGP revocation certificate: Whenever you create a new certificate (which again in the common case is every couple months due to the certificate lifetime, though you could reuse your certificate private keys which has its own set of security tradeoffs), use the certificate private key to sign a message along the lines of "The Let's Encrypt certificate with serial number nnnnnnn has a compromised private key." This could probably be automated with some kind of deploy hook, though of course securely transferring it to wherever you want to store this "revocation certificate" would take some care. There's not really anything built into the WebPKI to do such a cryptographic signature, but RSA and ECDSA allow for signing messages (that's how the fundamental TLS protocol works, after all.) I might recommend putting it in the format that pwnedkeys.com uses, perhaps using their pwnedkeys-prove-pwned program, which I'm guessing is as close to an industry standard that there is, but you may be able to hack something together yourself with an openssl command line like openssl dgst -sha256 -sign privkey.pem -out revokationmessage.sign <<< 'This key is compromised' and instructions on how to verify it.
Once you have a signed proof of compromise, that's your "revocation certificate". Keep it safe, give it to your buddy to use in case of emergency, and so on. If you need to use it, just email it to cert-prob-reports@letsencrypt.org and a human there will validate it and revoke the certificate within 24 hours.
And that last step, of course, is why I recommended at the beginning to not really build a process around this: It requires a human on the Let's Encrypt side, and so it isn't really scalable. Let's Encrypt is built all around automation, such that ideally everything goes through the ACME API protocol. But there is a stopgap available of getting a human involved for those rare cases that that's necessary. But I suppose if it were just you, for some weird reason you needed to do this sort of thing, and the 24-hour response time to actually get the revocation done was acceptable, it's a thing you could do.
Now, if this were a thing that multiple people needed to do, it might be worth trying to standardize some sort of attestation of compromise one could use, and an extension to the ACME protocol to allow for requests using it instead of needing to sign a request with the actual certificate or account key. But, well, I suspect it's the kind of thing that just isn't really needed.