I filed a bug in the bitcoinj tracker for this a few days ago referencing rfc 6967, but that RFC is very complicated and I'm not sure it's really necessary to go that far. H(sighash||key) is easy to implement and I feel I understand it better.
In our case it wouldn't have helped anyway - if anything it would just delayed discovery of the underlying weakness. The same RNG is typically used to generate both keys and signatures today. However in future it may be the case that people put more effort into generating a really random key because they only have to do it once, and then the signing RNG would be different.
Your concern about hardware devices leaking private key bits via a side channel is also well made, although I think you have to find some way to establish trust in these devices anyway as sniffing all their IO traffic and analysing it is really hard (plus it inverts the threat model - if you trust your computer and not your hardware wallet, why do you have a hardware wallet?)
The other advantage is that deterministic keys and signatures together mean two instances of the same wallet generate identical transactions given an identical sequence of commands. This could help keep wallets in sync. For example we had a few users who got confused because they had cloned their Android wallets across devices (NOT SUPPORTED!) and then one device updated first, did key rotation, and then the other device showed a transaction that sent all their money to a new address it knew nothing about. If they didn't realise the other device had updated this looked identical to theft!
I don't think fractional BIP numbers are the way to go :) but a new BIP that standardised a way to select K would, if reviewed, be something I'd implement.