I'm sure Intel loved that idea, given that I don't think RDRAND showed up on AMD chips for 3 years after Intel launched support for it, and that would let them look much better on a number of benchmarks for that duration...
I think you misunderstand where in the pipeline RDRAND would sit. It's not a high-performance RNG, that instruction takes hundreds of cycles and generates a couple bytes of data. It's used to derive keys for the actual CSPRNG providing e.g. /dev/urandom (which is basically a stream cipher). Having or not having RDRAND would have no performance impact on the CSPRNG.
Sure, but as I recall, in those days, the system would happily block for a bit if you managed to drain the estimated entropy pool low enough by doing something like generating an openssh key on first boot, so having another source that the competition takes 3 years to implement could have provided noticable performance benefits for things people notice, like how slow first boot is, in the days before zx2c4 looked at Linux's /dev/random code and hit it with hammers.
(I'm not insisting on that workflow or example being an uptick, just that that's a concrete example of how having an additional source back then could have caused noticable performance differences. I'm aware you're not calling rdrand for your /dev/urandom or random accesses, now or then.)
