I do worry that standardizing on a non-deterministic nonce generation scheme makes the problem of private key exfiltration a much bigger concern in the application of hardware signing devices.

While sorely imperfect, with a deterministic nonce scheme, we at least have the option of spot checking hardware devices to see if they are producing signatures in accordance with their specified nonce scheme.  But short of providing some kind of certificate, we won't be able to do such checks against hardware devices that use the proposed synthetic nonce. (Question: can a hardware device safely output the random value 'a' it used its "certificate"?  AFAIU 'a' is not considered secret data; it just needs to be not under attacker control.  Should hardware wallets be encouraged to return this value?)

The best way to mitigate this is to use the Nonce exfiltration protection mentioned; however there are no references on how to do this.  Ideally we'd standardize this Nonce exfiltration protection scheme within this synthetic nonce scheme.  However, I don't think it is worth holding this BIP up on that; it seems reasonable to introduce a new section to this BIP addressing that problem in the future.  Maybe instead we can get references to more information about this Nonce exfiltration protection that is mentioned?

Really I just want to do whatever we reasonably can do to avoid a world where we end up providing hardware signing devices with a hard to detect underhanded communications channel.