To clarify – or, more likely, to write a wall of text and make things less clear:
We don’t know for sure whether Let’s Encrypt tried to submit that final certificate to any CT logs or whether it succeeded.
We know that they issued it, stored it, made it available to the certificate download API, and are properly handling OCSP.
I submitted the certificate to several CT logs. (Anyone in the world can submit a public certificate to a public CT log. You just need a copy of the certificate and the intermediate(s) and some CT software. You don’t need to be a CA or have access to any private information possessed by the CA or the subscriber.)
My actions are why it shows up on crt.sh and, now, Censys.
The problem is that visibility into Certificate Transparency is cloudy. [sound effect] A human can’t read CT logs directly with a web browser and their own eyes. You need software to do it. Websites like crt.sh and Censys run software to download data from the CT servers and provide a human-friendly interface to it.
But, for a human to use one of those websites to to learn what’s going on, you’re relying on how the website is implemented, whether it’s working correctly, and even whether it’s honest.
To make up a simple hypothetical example, if you were using a CT website that only updated once a day, you wouldn’t have any idea whether a certificate issued a few hours ago was logged.
I believe Let’s Encrypt logs final certificates to the Argon and/or Oak logs. (I also submitted it to those two logs, among others.) Censys appears not to track Oak (it’s new). And crt.sh is backlogged processing them both:
Going by Censys’s data, it appears that Let’s Encrypt did not successfully log the certificate in question to Argon, but I don’t know whether they logged it to Oak.