**The only reason to use /dev/random is to _wait until the system has loaded entropy_.  If you have waited once, it is generally safe to use /dev/urandom.**  It has nothing whatsoever to do with _speed_ of output.  There is no reason to ever read more than a single byte from /dev/random in an application.  Writing a benchmark that measures time to read long outputs from /dev/random is incompetence bordering on dishonesty.  Writing an application like GnuPG that reads more than a single byte from /dev/random is incompetence bordering on malpractice.  The only excuse is that the historical documentation of /dev/random was also incompetence bordering on voodoo.

**In general, to be secure, _any_ random number generator must have at least a minimum amount of entropy—say, 256 bits—after which point you can safely draw arbitrarily long outputs using whatever pseudorandom number generator you like.**  There are perfectly good stream-cipher-based PRNGs.  There are perfectly good sponge-based PRNGs.  It doesn't make much of a difference to security which one you choose as long as it provides an adequate security level.

There's no reason that the PRNG has to be on the same hardware IC as the entropy source.  **Indeed, it is better if you can scrutinize the raw output of the entropy source to confirm that it has the biases it is predicted to have before you wire it up to a PRNG.**  If the IC just stores a secret key $k$ and a count $c = 0, 1, 2, \dots$ of the number of requests made to it, and returns $\operatorname{AES-256}_k(c)$, you will have no way to distinguish that from a true entropy source.  Of course, an adversary selling you these devices might write an elaborate simulator for the physical system it is advertised to have, but that won't be replicated if you fabricate your own instance of a free hardware design.