There are two relevant delays involved.
One is, individual Certificate Transparency logs are often parallel systems, they need to periodically perform a step to synchronise things so that what they tell the world (about certificates they have been shown) is consistent. They are prohibited from ever saying anything inconsistent (e.g. saying once that they’ve logged a particular certificate and then later that they did not) but they have up to 24 hours (called the “Maximum Merge Delay”) to deliver a new consistent view after logging the certificate. Of course it doesn’t take 24 hours to do the mathematics, but this is the absolute maximum delay, it includes for example if they have a power failure or network interruption, they must recover and publish new consistent records in under 24 hours if they’d signed any SCTs before they lose power / network. The chosen MMD is a compromise, a longer MMD would allow logs to recover from more serious failures, e.g. the whole of Japan is destroyed by a rampaging lizard monster, whereas a shorter one would detect problems more quickly.
The second is that crt.sh itself [run by Comodo] needs to suck in the millions of certificates from the dozens of active logs, it is able to mostly keep up, but it isn’t live. https://crt.sh/monitored-logs shows crt.sh’s view of its own backlog, the difference between the number of certificates it knows it should have record of, and the number it already has downloaded from the logs. It is normal for there to be a significant backlog for the very popular logs used by Let’s Encrypt.