You don't need a hardware RNG. If you're running a modern Linux distro, you can safely just pull as much randomness out of /dev/urandom as your heart desires.
I recommend copy-pasting the document, deleting all the "myth" garbage, and reading the explanations.
Mere requirement of knowing every execution and failure state in TCB eliminates Linux + /dev/urandom instantly. Some FSM's + some analog circuits can be verified by eye, hand, and formal verification if desired.
Now the certification bodies, paperwork focus, etc can be harmful. It's why I got private evaluations for my stuff. I saw Sentinel do same for HYDRA using NSA and Secure64's SourceT (medium assurance) had positive review from Matasano for its POLA/resilience. And that's COTS. Sirrix too using Nizza architecture with tiny TCB. So, the basic principles are there, improvements are often dramatic, several companies are doing it, and so rest have no technical excuse for using weaker methods.
Also, most people have things they do not need. For example, one doesn't need a tablet, whiskey, or windows in their dwelling.
Do you mean there are any special cases situations where entropy is extremely low? Just after reboot? Just after first install? Just after booting a VM from an image (where the "entropy" could be public knowledge)? Container?
1. Breaking urandom's construction is much less likely than breaking a less-trodden hardware device.
2. If hashes in general are broken, then any crypto of interest is also broken (counter example: non-complexity based crypto like a one-time pad (note: Do NOT construe this as any sort of practical endorsement of "one time pads". If you do not understand the concept of malleability, then forget this entire comment exists and go read up on that instead!)).
3. Backdooring RDRAND is equivalent to backdooring the entire CPU (counter: a model of auditability that constrains the complexity of a backdoor)
These assumptions are mostly reasonable, but they are assumptions nonetheless.
Embedded systems do suffer from a demonstrable lack of entropy. Studying techniques for hardware entropy collection is interesting in its own right, which is why it's disappointing that this page seems more focused on productizing their device as a black box USB stick rather than concentrating on open review.
This device apparently generates reliably a 300 Gbps random stream. Not easy/cheap to do with DRBGs. But as I said, I have no idea of any application where this would be required.