I should say that this is the danger of /dev/urandom rather than /dev/random. Non-blocking behaviour assumes nothing about the entropy in the pool and therefore while the underlying PRNG algorithm may be the same as /dev/random, the output will still potentially be weak even though the output might look random.

Here's a concrete example I like to use:

Say you have a DRBG/PRNG that has the following algorithm: starting at num=1 emit byte streams from sha1hash(num). Then increment to the next number and repeat. The resulting output stream will be indecipherable from random noise because sha1 is cryptographically strong. But the seed material is incredibly weak. (The algorithm is not really an issue in this case because it's just a deterministic algo with a hash conditioning function.)

I believe that the primary problem is simply waiting for high quality bits of entropy. High quality DRBGs are all about "quality in" = "quality out". Testing the quality of that entropy is actually a bit harder than it seems and in my line of work, we tend to overestimate how strong those sources of entropy are. If you need to generate 256 bit AES keys, then you need at least 256 bits of entropy: which is not the same as typing 256 random keys on the keyboard to get it. You might only get 1 bit of entropy for every 20 bits streaming into the entropy pool -- and this is the real danger of /dev/{u}random, rather than any blocking or non-blocking behavior.