Achow's post seems to sound like it's saying that there is some kind of danger in random K because of 'getting more information out' -- there isn't in and of itself, to the extent that different K's "get more information out" so does signing multiple messages.
The reason for 6979 is that reliably generating random numbers is hard and it turns out that over and over and over again applications screw it up. Worse, you can't easily tell when a random number is screwed up because it's random, one looks as good as any other. ... unless the screwup is so bad that they're just constantly repeating. But basically any form of predictability of K will break the signature, even ones like being linearly related to the Ks in other signatures.
You still need to generate a secure random number to get your private keys, but you only need to be successful at that _once_. RFC6979 is really just a way to safely reuse that ONE random number you successfully got (the private key) for all your further transactions... rather than needing a constant influx of new random values, each one a potential point where a software error could cause the loss of your keys.
The fact that the procedure also gives the same signature every time for the same key/message if you don't use the optional extra-data input to 6979 is a bonus that makes software testing a lot easier, but it is not the source of the advantage of this approach itself.
This distinction is important because multiparty schnorr (or mpc-ecdsa) signing can use RFC6979 but MUST be constructed in a way where the same signature is not repeated even for the same message.
