What a mess. The problem here is systemd and/or things like GNOME wanting high quality entropy too soon, often not actually even needing it. Systemd shouldn't need high-quality entropy for itself, and most services it starts shouldn't need any either, though eventually some service is bound to need it (e.g., for TLS), but each service should make its own decisions about early-in-boot entropy. Then instead of a deadly embrace between the kernel and systemd leading to not making progress in boot you'd have some services not quite operational right away -- still a big problem, but a lesser one.
Still, if you're booting a system that will be doing one thing, and that one thing needs entropy, then you have a problem. And the only practical solution then is to accept using things like RDRAND and a previous shutdown's saved seed to seed the system's SRNG, then add better entropy slowly as you can get it.
EDIT: I agree with tytso: if you trust the CPU enough to run on it, then you should trust its RDRAND or equivalent (if it has it).
RPis don't necessarily have RDRAND, they especially suffer from increasingly fast boot where waiting for the entropy pool is an actual concern.
Of course, not all applications need that kind of cryptographic entropy but during early boot it's pretty much the best randomness you can get (seeding from datetime isn't available on the RPi, so until you can bring up the network and contact the NTP server, you're stuck with whatever getrandom() returns)
Still, if you're booting a system that will be doing one thing, and that one thing needs entropy, then you have a problem. And the only practical solution then is to accept using things like RDRAND and a previous shutdown's saved seed to seed the system's SRNG, then add better entropy slowly as you can get it.
EDIT: I agree with tytso: if you trust the CPU enough to run on it, then you should trust its RDRAND or equivalent (if it has it).