Preliminary: no matter how good the method to generate the nonce $k$ in ECDSA is, it will not prevent LadderLeak, which is a side-channel attack independent on bias in the generation of $k$.
The technique in RFC draft-irtf-cfrg-hash-to-curve-16 section 5 can be adapted to generation of nonce $k$ in ECDSA instead of what RFC6979 recommends. The general sketch being that we generate nonce $k$ in range $[1,n)$, deterministically from the ECDSA private key† and hash of message being signed, where $n$ is the curve's order.
The RFC's method generates $m$ values in $[0,p)$ (by their notation), thus we'd want‡ to set $m=1\,$, $p=n-1$, and add $1$ to the one generated integer in $[0,p)$ to obtain nonce $k$ in $[1,n)$. We can do this by inserting a $+1$ as step 7 in the algorithm, making it $e_j=(\operatorname {OS2IP}(\mathrm{tv})\bmod p)+1$.
There's a certificational issue, that we can just ignore: the RFC's technique is intended to generate a field element, thus is stated for prime $p$, which would not be the case for $p=n-1$. However the RFC's technique happens to work unmodified for any $p>0$; it just does not generate a field element (it's stated goal).
Critically, whatever implementation of the RFC's techniques must not create a side channel (on the private key, or on the generated nonce $k$), which could allow an attack.
Regarding the acceptable bias in the generated nonce $k$ in ECDSA: rest assured there is no danger whatsoever in using $\mathtt{L}=48$ byte in the RFC when generating a nonce $k$ of 32 bytes (corresponding to security parameter of 128 bit in the RFC).
- If we can't distinguish the generated nonce $k$ from random (which is the claim of the RFC), it's good enough for ECDSA without having to even think about what attack we consider (argument: whatever attack on ECDSA based on the bias on nonce $k$ would allow to build a distinguisher invalidating the RFC's security claim).
- Actual adversaries are limited in the number of signatures they can obtain. Even $2^{64}$ is wildly unrealistic (especially if we consider the fact they must be for the same public/private key pair). Thus we could do with 64-bit security, and 128 is way overkill.
† No relation to the nonce $k$ designated in the question as "32-byte private key".
‡ Alternatively we could as well set $p=n$, and discount the probability that the nonce generated is zero by accident. It's however sensible to test against that at some point, and that must be in a side-channel proof way, including but not limited to constant time. If this condition triggers, either something is broken or we are under attack, and a sensible reaction is to zeroize all sensitive material, perhaps the private key.
