/dev/urandom does have a problem with not enough entropy sometimes. Yes it never "runs out" of entropy when it has enough previously. But when a computer first boots up, sometimes it doesn't have enough entropy yet, and gives bad output.
Yes in that case you want to use getrandom/getentropy.
Also note (as TFA indicates) that urandom not blocking on uninitialised entropy pool is mostly a Linux thing e.g. BSD urandom will block until the system the system is correctly initialised.
"that case" is every case unless you know and control exactly which OS, on which (potentially virtual) hardware and under which circumstances your code is going to run, now and in the future.
That excludes anything that is meant to be used by other people. Fragile security is no security, and relying on undocumented assumptions like "is not running on Linux", "starts late in the boot process" and "is not running on an VM" is incredibly fragile.
Unfortunately people who really should know better keep writing articles like this one, dispelling the "myth" that urandom works exactly as documented.
Oops, hope none of that was for anything important, say generating a long-term cryptographic key! But of course if we're to believe TFA... "Fact: /dev/urandom is the preferred source of cryptographic randomness on UNIX-like systems."
Just use getrandom. If you can, consider using only getrandom. But if your code must work on systems without getrandom or similar, before following the advice of this article, ask yourself if what you are doing is worse of blocking, or reading out a grand total 3 bits of entropy. You'd probably prefer the former.
The bug report also explains what systemd is doing here.
"systemd starts allocating those hashtables very very early on, before any process is forked off... It's par tof the initialization scheme of systemd really. Hence there's basically nothing else going on in the system, execept what is done by the kernel itself", -- Lennart Poettering, 2016-05-05, https://lists.freedesktop.org/archives/systemd-devel/2014-Ma...
"moving that blocking behavior to /dev/urandom simply does not work. The system does not boot. The reason to this issue is actually quite simple. The init process of systemd reads /dev/urandom for whatever purpose. Now, when /dev/urandom blocks during boot, systemd will be blocked too." -- Stephan Mueller, 2016-10-22, https://lkml.org/lkml/2016/10/21/982
This causes problems in practice, allowing people to crack RSA private keys. https://factorable.net/weakkeys12.extended.pdf