The argument that the random numbers from the RdRand instruction cannot be trusted, compared to the kernel RNG algorithms that extract entropy from interrupt timing doesn't really hold water. Especially in light of the recent studies showing the lack of boot time entropy.
To suggest that users 'wait' for entropy to be available from the kernel when their platform provides copious amounts of entropy before the first instruction has executed suggests that it is the kernel that is the problem, not the platform or user behavior.
Compared to the treatment of most CPU logic, Intel has been extraordinarily open with the design on the RNG, exposing the full algorithmic details and opening the design for external review. I've yet to see an comparable expositions of why we should believe the Kernel entropy gathering code achieves a well defined min-entropy.
When a user has paid for and deployed a RdRand capable machine that solves their boot time entropy problem, it is not in that user's interests that a paranoid design philosophy in the kernel leads to the user getting no entropy, rather than the 150MB/s+ that the platform can provide. They need the random numbers, not advice on who to trust and they should get those numbers if they trust the platform they run their software on.
Lack of entropy has been a problem that has dogged computer security for decades. Now that we are in sight of a comprehensive solution in hardware, the right approach for the kernel is to facilitate high bandwidth access to entropy through the /dev/[u]random interfaces, drawing from the underlying hardware.
The right approach for application software is to dispense with slow, large attack surface libraries and kernel calls and use the instruction based sources directly, rendering themselves immune from a large class of side channel and memory based attacks that can be raised against software entropy extractors and PRNGs. Existing and new software might continue to use /dev/[u]random, but where security and performance are a goal, RdRand and AES-NI are simply better.
The primary goal of RdRand is to make the platform entropy problem simply go away. In time it will, but we are in a position to speed the process by making the right design decisions, so the non cryptographers stand a chance of their security software working for them.