The fallacy in this question is that there is no such thing as “draining entropy”. (Not in any sense where you'd run out of entropy before the universe runs out of a lack of entropy to let you live in it.)
Any random generator designed for cryptography needs two elements: an entropy source, and a way to “smooth out” the entropy source. Entropy sources are not sources of random bits, they have biases that need to be kinked out. An unconditioned entropy source is no good for cryptography. Conditioning, i.e. turning an entropy source into a source of uniformly random bits, is done by a cryptographically secure pseudorandom number generator (CSPRNG for short). Once a CSPRNG has been seeded with enough entropy, it's good to go for at least a few lifetimes of the universe¹.
/dev/urandom uses a CSPRNG which is periodically reseeded with extra entropy. The periodic reseeding helps in case of a partial compromise of the machine that somehow leaks the internal state of the random generator.
/dev/random uses a CSPRNG which is periodically reseeded with extra entropy. (Sounds familiar?) Linux maintains an internal calculation that assumes that the CSPRNG algorithm is badly broken and leaks entropy at a rapid rate and blocks
/dev/random. But if you don't trust the crypto behind the CSPRNG, you can't trust even what
/dev/random gave you in the first place, or pretty much any other crypto that you'd be using.
So no, draining the entropy does not make your system more vulnerable in any way.
The only risk with Linux's
/dev/urandom is that it happily gives you predictable output before it's been properly seeded. This isn't a concern for day-to-day use on a “normal” desktop or server computer because they save the entropy pool on disk. It is a concern if you have a freshly installed system, or a live system that boots from read-only media. (A live system is a bad place to generate long-term keys!) Once the system has enough entropy, that's forever.
If you want a professional cryptographer's take on this issue, you can read Thomas Pornin's or Thomas Hühn's.
¹ N bits of entropy take 2N calculations to figure out. If you generate a billion bits per second, and you start with a decent security level of 128 bits, 1 universe-life gives you time to generate about one sextillion bits, which is 296, comfortably below the limit.