Well, I guess "there is absolutely no security benefit to using /dev/random, for any cryptographic application" is a slight overgeneralization, because a one ti

Well, I guess "there is absolutely no security benefit to using /dev/random, for any cryptographic application" is a slight overgeneralization, because a one time pad is, as you say, a cryptographic application. But not much of one because the vast majority of the time you are not generating a one time pad. As for forward secrecy, as I understand it, /dev/urandom is constantly updated with more entropy to maintain forward secrecy. In fact it is updated in exactly the same way as /dev/random. The only difference between /dev/urandom and /dev/random is that /dev/random blocks when it deems you have "run out of entropy" (which is really nonsense). So even if the saved seed is compromised, as soon as enough new entropy comes in, /dev/urandom will be secure again. Also note that if the seed is compromised, /dev/random is not much better because it doesn't know that the seed has been compromised. So /dev/random will freely produce for you up to N bits of tainted output based on the broken seed, where N is the current entropy estimate.