I disagree, either the entropy is drained and the randomness of what the pool returns (based on OS) is compromised or you get stalled waiting for more of it and decrease performance of the generator.
A simple thought exercise to show you how false this is:
Instantiate AES-128-CTR with a random key. Encrypt 100 megabytes with it. Have you "drained" "key" from AES? No, not in any meaningful sense. If you could, the AES-CTR recommendations would say "don't encrypt more than 100 megabytes with AES-CTR". In practice, people routinely encrypt many gigabytes with it.
Every modern OS uses a DRBG for its kernel CSPRNG. You can think of a DRBG as a stream cipher, just like AES-128-CTR, where random events are hashed to form the key, and the output is the raw keystream. Asking for 100 megabytes of additional keystream doesn't "drain" the "key" from the keystream.
Linux has a terrible misfeature, born of a failure to understand the crypto primitives they're using in their CSPRNG. /dev/random keeps an "estimator" that tries to determine how much "entropy" has been fed to the CSPRNG, and it decrements that estimator when requests come in for random bytes. Linux claims you can drain its CSPRNG. Linux is wrong; that is not how crypto works.
Linux should lose that feature, but they will not. But there's no reason you should have to go along with it; just use urandom, which will not block for the estimator.
I think entropy, in however you measure it, does influence something like a UUID generator differently than the cryptographic algorithms. What you are trying to achieve, or more importantly the condition you are trying to avoid, is different.
Instantiate AES-128-CTR with a random key. Encrypt 100 megabytes with it. Have you "drained" "key" from AES? No, not in any meaningful sense. If you could, the AES-CTR recommendations would say "don't encrypt more than 100 megabytes with AES-CTR". In practice, people routinely encrypt many gigabytes with it.
Every modern OS uses a DRBG for its kernel CSPRNG. You can think of a DRBG as a stream cipher, just like AES-128-CTR, where random events are hashed to form the key, and the output is the raw keystream. Asking for 100 megabytes of additional keystream doesn't "drain" the "key" from the keystream.
Linux has a terrible misfeature, born of a failure to understand the crypto primitives they're using in their CSPRNG. /dev/random keeps an "estimator" that tries to determine how much "entropy" has been fed to the CSPRNG, and it decrements that estimator when requests come in for random bytes. Linux claims you can drain its CSPRNG. Linux is wrong; that is not how crypto works.
Linux should lose that feature, but they will not. But there's no reason you should have to go along with it; just use urandom, which will not block for the estimator.