Cryptographers seldom, if ever, actually need true random numbers continuously and by the hundreds of megabit per second (or more), as in what's quoted. They do need random bits/numbers continuously at often much higher rates, and use Pseudo Random Number Generators towards that.

The only actual use that I know of >1 Mbit/s true random bits is to gather, with very small latency, a few hundreds of random bits that an adversary can't guess by side channel attack in cryptographic hardware designed to resist such attacks; in such application it is more convenient (uses less silicon), and safer, to generate these bits, than to gather them in a buffer; and since the latency is $t=n/r$ where $n$ is the number of bits wanted and $r$ the bit rate of the source, there is incentive for large $r$.

I can also imagine an hypothetical device that needs to be operational a millisecond after power is applied, and uses crypto, which would have need for a fast TRNG for similar reasons.

Cryptographers often need values that adversaries can't guess, and for that purpose true random numbers (that it, derived from natural phenomena believed un-modelizable by adversaries) are a must. Uses include

1. key of an algorithm (including generating the keystream of a stream cipher)
2. challenge in a protocol (or nonce generated by a memory-less device)
3. choosing a random element in a set (or clock cycle at which some action takes place)
4. protection against side-channel attacks of a cryptographic device
5. keystream generation in a One Time Pad

In 1/2/3, it is not needed a lot of true random numbers; true entropy of 512 bit (which can be gathered by post-processing say 1024 bits produced by a source with a little bias and cross-correlation between bits) is usually more than enough for each use.

In 4, which occurs in Smart Cards and other cryptographic hardware, there's a need for a significant amount of bits that an adversary can't guess (about proportional to the data manipulated, with a multiplicative factor that varies between implementations); and because we are fighting leakage, the safe thing is to assume that a Pseudo Random Number Generator could be attacked by side channel too, thus it makes sense to use true randomness (with just enough post-processing to remove discernible bias, if any) as the source of the randomness; also, that simplifies the hardware.

In 5, if we did not use true randomness, we would be back to a stream cipher as in 1. Thus, by definition, it is needed as much true random bits as there is data transmitted using the OTP. But fact is, because the pad in the OTP must be securely transmitted, the OTP is extremely inconvenient, and I do not know that anybody is currently using it for significant amount of data; it historically has been used for small amounts of data, and occasionally broken, either because the pad was intercepted, or because there was not enough pad available and a pad was reused.

Cryptographers seldom, if ever, actually need true random numbers continuously and by the hundreds of megabit per second (or more), as in what's quoted. They do need random bits/numbers continuously at often much higher rates, and use Pseudo Random Number Generators towards that.

The only actual use that I know of >1 Mbit/s true random bits is to gather, with small latency, a few hundreds of random bits that an adversary can't guess by side channel attack in cryptographic hardware designed to resist such attacks; in such application it is more convenient (uses less silicon), and safer, to generate these bits, than to gather them in a buffer; and since the latency is $t=n/r$ where $n$ is the number of bits wanted and $r$ the bit rate of the source, there is incentive for large rate $r$.

I can also imagine an hypothetical device that needs to be operational a millisecond after power is applied, and uses crypto, which would have need for a fast TRNG for similar reasons.

Cryptographers often need values that adversaries can't guess, and for that purpose true random numbers (that it, derived from natural phenomena believed un-modelizable by adversaries) are a must. Uses include

1. key of an algorithm (including generating the keystream of a stream cipher)
2. challenge in a protocol (or nonce generated by a memory-less device)
3. choosing a random element in a set (or clock cycle at which some action takes place)
4. protection against side-channel attacks of a cryptographic device
5. keystream generation in a One Time Pad

In 1/2/3, it is not needed a lot of true random numbers; true entropy of 512 bit (which can be gathered by post-processing say 1024 bits produced by a source with a little bias and cross-correlation between bits) is usually more than enough for each use.

In 4, which occurs in Smart Cards and other cryptographic hardware, there's a need for a significant amount of bits that an adversary can't guess (about proportional to the data manipulated, with a multiplicative factor that varies between implementations); and because we are fighting leakage, the safe thing is to assume that a Pseudo Random Number Generator could be attacked by side channel too, thus it makes sense to use true randomness (with just enough post-processing to remove discernible bias, if any) as the source of the randomness; also, that simplifies the hardware.

In 5, if we did not use true randomness, we would be back to a stream cipher as in 1. Thus, by definition, it is needed as much true random bits as there is data transmitted using the OTP. But fact is, because the pad in the OTP must be securely transmitted, the OTP is extremely inconvenient, and I do not know that anybody is currently using it for significant amount of data; it historically has been used for small amounts of data, and occasionally broken, either because the pad was intercepted, or because there was not enough pad available and a pad was reused.