On a general basis:
/dev/urandom is no less secure than /dev/random. In fact they both use the same algorithms and the same seeds. Occasionally, /dev/random just stops because someone, someday, read something about entropy, did not understand it, and now thinks that randomness is something that is burned upon usage and must be refilled regularly.
(This page makes a rather nice job explaining things on that subject.)
There can be situations where there is not enough available entropy in the whole system. These situations do not occur with normal Linux distributions because they generate and save a random seed at boot time, to be used for the next boot, effectively ensuring that /dev/urandom is cryptographically secure all along. To get into one of these situations, you have to either play some weird games with VM snapshots, or use not a PC but some very limited embedded system; this is quite far from the contexts where you would use GnuPG.
It is very noteworthy that in the case of VM snapshots, the "entropy estimate" of /dev/random will gleefully report that it is full of the stuff, which is, in this case, very wrong. That is, not only does the blocking behaviour of /dev/random is scientifically unsubstantiated, but it also totally fails to be triggered in the one practical case (VM snapshots) were entropy loss could be feared.
Also remember that contexts where /dev/urandom is inappropriate are also contexts where /dev/random is inappropriate. Using /dev/random will not make things "more random"; at best, it will refuse to work instead of generating a key of theoretically lower security ("theoretically" because none of this has ever resulted in a practical break, even as a demonstration in lab-controlled conditions). As explained above, this is really an "at best" and it won't actually work that way with VM snapshots and reset.
Fortunately, all the activity involved by a boot implies collection of enough entropy to achieve cryptographic security (for arbitrarily long /dev/urandom outputs, even). See this article for more analysis. GnuPG key generation is not done by the kernel in the early boot steps; it occurs much later, during normal operation, when the PRNG has been properly seeded.
None of this prevents some people from insisting on some ritual dancing with entropy. Apparently, the GnuPG authors are part of that specific theological interpretation -- either because they believe it or because they yield under the market pressure.
Summary: using /dev/urandom instead of /dev/random is not weak for GnuPG. GnuPG is used in a context where /dev/urandom is properly seeded and will achieve all the required unpredictability, and /dev/random will do no better (not in practice, not in theory either). In the one situation (VM snapshots) where the output of /dev/urandom could be inadequate for GnuPG, the output of /dev/random will be equally inadequate for the same reasons, and the blocking mechanism of /dev/random will not be triggered. The conclusion is that switching from /dev/urandom to /dev/random for GnuPG is completely useless.
... that is, from a technical point of view. Using /dev/random instead of /dev/urandom could induce some blocking that can help in persuading the weakly-minded that "serious cryptography is happening". It won't make things more secure, but it may make the user feel safer.
