We had a discussion about this on IRC. While I think it would be good to document this reasoning, I think it was addressed:
* RFC6979 itself specifies a very similar form of iteration to produce nonces, to make sure they are in the valid range (between 1 and the group’s order). For secp256k1 this is not observable, as the order is so close to a power of 2 (2256 — 232 — 977), but for other curves it is an actually practically observable bias. Clearly the authors of RFC6979 did not consider this to be an issue.
* The information «whether or not the first generated nonce was Low-R» was already available in the old scheme as well, by virtue of revealing the first R value. The only additional information to a timing attacker in the new scheme is how many iterations were needed (if more than 1).
* In general, to meaningfully reduce the nonce space for an attacker, requires in the order of 2256 hashing operations. This is far slower than a direct ECDLP attack on the R point or public key itself. As the information does not lead to a more efficient attack, it does not reduce security.