So NIST, Google, Apple, Cloudflare, and others are taking this seriously.
A lot of folks look to LetsEncrypt to be a leader here. The standards may change, but it's prudent to be up-to-date.
Thank you for your consideration for the roadmap!
While you can of course add anything to the roadmap, I find it a bit early for Let's Encrypt to state anything until the cryptographic community has sorted things out a bit more. There's currently no clear guidance on what a Post-Quantum PKI should look like. There's no code in the common HSM modules etc. Let's Encrypt can't just do what they want, there are rules to follow and a hastily written PQ PKI may result in a security disaster.
There's currently a push for PQ-hybrid key exchanges in security protocols (SSH, TLS, IPSec). That's relevant because of store now, decrypt later attacks. It is assumed that there are presently various actors at play who store large quantities of secure sessions (e.g. TLS) to decrypt them at a later point in time using a Quantum Computer. It is therefore relevant to defend against these attacks now, as they're possibly happening right now.
The PKI system on the other hand cannot be attacked after-the-fact, because it provides authentication, which can only be broken live. Therefore, the security community is currently focussed on securing the key exchange. Adding PQ secure authentication will probably happen at a later point. There's still a lot of work to be done on designing this PQ PKI scheme, and it's important that this is done with great care - or you will end up with a system that's not secure at all.
It's important to understand that our security knowledge on the PQ algorithms is still... thin. For instance, NIST was relatively close to standardizing the Rainbow PQ signature scheme, up until this paper came along: Breaking Rainbow Takes a Weekend on a Laptop (The scheme was withdrawn in a coordinated manner shortly before Beullen's work was made public)
"Unfortunately", every publicly trusted CA, thus including Let's Encrypt, needs to abide by the CA/Browser Forum Baseline Requirements. Those BR don't even accept Ed25519 yet, but just the NIST curves..
Until the BR have been changed to allow other algorithms, there's nothing LE can do. Except perhaps suggest a change to the BR. But any CA or browser member of the CA/B Forum can do that..
So while I understand your request, it's not up to Let's Encrypt to suddely implement these things.
Just to put some of what @Nummer378 wrote in context: The Cloudflare research is on Key Agreement within the TLS Handshake; that is independent of x509 Certificates. The NIST research they cited, and later linked to, is also regarding Key Agreement and digest computing within the TLS protocol.
This is all stuff that will eventually be implemented by the servers/gateways/CDNs that ISRG runs the LetsEncrypt service on. This stuff is all independent of the Certificates themselves.
While some of the new research deals with calculating digests, LetsEncrypt's digests are communicated through TLS encrypted payloads between the server and client - so there isn't much of an immediate concern there. The current weak spots in the ecosystem, and the immediate target of improvements, are all in the key exchanges.
In terms of changes to Certificates (such as key types), that is driven by the CA/B forum baseline requirements. Extensions or changes to the ACME protocol would require a mix of IETF support and CA/B Forum acceptance. TLDR on that is that we're not able to see any change on those things unless there is hotfix to a compromise, or several members make a coordinated push to fasttrack a new standard. LetsEncrypt staff have made it clear they want to fasttrack new PQ standards once the ecosystem is more stable - things are simply at a place now where there is a 99.9% chance all their work would be experimental R&D that is immediately obsoleted.