Could you elaborate on this, or share a link or two?

This is several years old now, but it is an overview of a (failed) attempt to replace Linux's existing random implementation with Fortuna, an improved variant of the Yarrow algorithm used by FreeBSD, and a comparison with Linux's existing random implementation.

http://jlcooke.ca/random/

This is a thread on LKML about adding support to Linux's random implementation for Intel's RdRand instruction. You have to read all the way through to see the extent of the insanity. ("We can't trust Intel because NSA backdoor government spying chemtrails HAARP fluoride wharrgarbl!")

http://thread.gmane.org/gmane.linux.kernel/1173350

I can't find the LKML thread to link to it, but earlier this year, there was a hullabaloo over a paper published at https://factorable.net/ regarding network-connected devices generating weak keys because of "insufficient randomness" at boot time. This led to a reworking of how/when/why entropy is fed into Linux's entropy pool.

How is it unreasonable for open-source OS developers to be concerned about closed-source blobs in cryptographic components?

The entire CPU is "closed source." If you can't trust the CPU, then it's game over for everything you're doing on the CPU.

Trust isn't binary. Backdooring or exploitably bungling the deterministic parts of the CPU without getting caught is much harder than doing the same for the RNG part. Black box RNG's are notoriously hard to evaluate.

Also, I don't remember anyone getting publicly bent out of shape about including AES-NI support in Linux's CryptoAPI. (I'm unsure why people would think Intel would backdoor RdRand but not the AES-NI instructions.)

The output of AES-NI is easy to verify. You can't verify random numbers generator.