Seed / reseed DRBG too often?
/dev/urandom itself is an acceptable crypto-quality (P)RNG. Therefore it can't hurt security to call it as often as you want. Assuming that /dev/urandom operates correctly (i.e. returns bit that cannot be predicted), the probability for an observer to correctly predict the bits generated by drbgFromSeed decreases (very slowly) with the number of generated bits.

You could, in fact, read from /dev/urandom and never use a DRBG internally. There are reasons not to do that, but they aren't security:


The most common reason to avoid reading /dev/urandom too often is performance.
You may prefer to use a know PRNG internally and keep outside sources as strictly entropy injection. This would make your application portable to platforms that don't provide a usable PRNG, and you have to make do with something else (e.g. downloaded or pre-seeded entropy).
Using your own DRBG implementation (or a known good one) can help if you need to demonstrate the security of your application.
Maybe you need the determinism property at some point — but then you're better off using an explicit KDF.


What you need to be extremely careful of is never using the same DRBG state more than once. Discarding a DRBG state is fine. The DRBG state has an affine type (your syntax looks like Haskell, beware that without a monad to enforce linearity, the mistake of reusing a DRBG state is a lot more likely than in an imperative language).