Their numbers are off and the explanation confusing, but they do have a point.
The algorithms used for RDRAND/RDSEED instructions are described in the software implementation guide (pdf). What it amounts to is that for RDRAND, some hardware entropy is conditioned and used as a 256-bit seed for AES CTR_DRBG (from SP 800-90A).
The same 256-bit seed is used to create up to 1022 64-bit random values, if called quickly enough. Since up to 65408 bits are generated from a 256-bit seed, you can't concatenate them for arbitrary entropy.
Specifically, if you created a 512-bit value, it could "only" have about 256 bits of entropy. Do the math considering the 64-bit splitting and I think you'll end up with 257 bits in total: it's either one of the at most $2^{256}$ 512-bit values the AES CTR_DRBG can generate, or else it is the middle 512-bits of a 640-bit value. In that sense concatenating two 256-bit numbers adds a single bit of entropy.
When you consider combining two 64-bit numbers, however, that logic does not apply. There is no brute-force attack that will let you narrow it down to fewer than $2^{128}$ possible values. The DRBG would have to have a state smaller than 128-bits for there to be an attack, and that would no longer be cryptographically secure.
In comparison, RDSEED always returns independent numbers with entropy from the hardware RNG. That means they can be concatenated to arbitrary length numbers with full entropy.
The rationale for using cryptographic mixing is also wrong. If the inputs to the HMAC or AES combiners have only $n$ bits of entropy, then the output can't have any more either. The only way it would help is if some of the inputs (e.g. a longer term key) came from independently seeded instances of the DRBG.
The amount of work required...
, not the entropy. $\endgroup$