It's a valid question, with two possible threat models:
1) the honeypot uses your private keys to MITM connections
Let's Encrypt doesn't handle your private keys. You generate them yourself, and submit a CRL to LE to get a cert issued. They have no knowledge of your private key.
2) the honeypot issues fake certs
Let's Encrypt submits a log of every cert issued, see https://crt.sh/ . To verify, it'd be pretty trivial to create a browser extension (if one doesn't exist already) that checks whether certs you encounter appear in the certificate log.
For CT the finished system involves browsers checking that the server can prove its certificates were logged (the ones you get from Let's Encrypt have such proof embedded) and periodically talking to Log Monitors (e.g. owned by your browser vendor) about proofs it has seen.
If somebody has seen a proof that is contradicted by the published log state this means the Logs involved are corrupt. If an otherwise authentic cert is shown without proofs or those proofs are bogus the cert may have been unlogged for nefarious reasons, it shouldn't be accepted and needs reporting
Chrome has the start of this, it checks for the proofs. Firefox is getting roughly the same feature "soon". But the finished system with all bells and whistles is probably a year or five away.
Good news is that even unfinished CT has been very effective.
1) the honeypot uses your private keys to MITM connections
Let's Encrypt doesn't handle your private keys. You generate them yourself, and submit a CRL to LE to get a cert issued. They have no knowledge of your private key.
2) the honeypot issues fake certs
Let's Encrypt submits a log of every cert issued, see https://crt.sh/ . To verify, it'd be pretty trivial to create a browser extension (if one doesn't exist already) that checks whether certs you encounter appear in the certificate log.