I don’t see the Let’s Encrypt client trying to directly use its own RNG of any kind in place of the operating system’s RNG. However, if we think there are reasons why the OS RNG might be inadequately seeded, we might be able to try to find ways to seed it ourselves.
Getting entropy from a server can be better than the alternatives in some models.
On the bright side, the user has to type a little bit in order to run the Let’s Encrypt client, select options, and optionally enter a recovery e-mail address; hopefully the OS is getting something from the variable packet timings there, even on a freshly-installed and freshly-rebooted system.
We could also ask some of the hosting providers (or server OS developers) what they’re doing to try to ensure fresh instances are decently seeded, since it’s something that’s best dealt with overall at that level. The PGP experience may have misled people a bit this way: PGP was originally designed to run on systems like DOS that had no OS CSPRNG whatsoever, so your only possible CSPRNG was one that shipped inside the application. Most modern operating systems do have a supposedly decent CSPRNG that applications can simply use without doing their own entropy collection step, yet GPG and KeepassX and maybe some other applications don’t seem to trust it, maybe to their own detriment. The big risk as I understand it is not so much that an individual application would fail to collect entropy as that a key generation step could happen very early in the lifecycle of an OS boot, or on a machine that has unusually few sources of physically unpredictable events.