My question was for /dev/random. The main problem RdRand solves is quantity: obtaining a lot of random bits per second. Even if they were produced in a way that somebody knows possible weaknesses, mixing them with something cryptographically strong where we control the seed we'd preserve quite a high throughput. I know that there is /dev/urandom which can often be good enough, but I know that too much applications in fact prefer to use /dev/random so making /dev/random robust has sense.
I see Ted Ts'o commented too, and as I understand, having RdRand is still much better compared to having the platforms without it. There's a lot more to care about than is RdRand "perfect" and once you have something like RdRand you can use it safely enough, compared to not having anything.
It applies to /dev/random too - the same write() implementation is used kernel-side for both devices so it doesn't matter which one you write to.
The seed that is saved at shutdown and reloaded at startup will alter the internal state of the /dev/random pool, but it won't add to the entropy estimate (which makes sense). This means that the output will be more robust, but it could still block waiting for "real" entropy.
I see Ted Ts'o commented too, and as I understand, having RdRand is still much better compared to having the platforms without it. There's a lot more to care about than is RdRand "perfect" and once you have something like RdRand you can use it safely enough, compared to not having anything.