The goal of writing a BIP seems to be to get lots of different wallet authors to write lots of code for you - but I am a wallet author, and I don't think that's the right way to get traction with a new scheme.
For instance the TREZOR guys would have to support your new protocol otherwise if I paid my hotel bill with my TREZOR I couldn't open the door when I got there! But they probably have better things to be doing right now.
The key difference between just generating a client certificate and using a Bitcoin address is that the client certificate is something that is used specifically for identification. It leaves no trace in the block chain, so no weird privacy issues, it doesn't matter how you manage your wallet, and you don't have to persuade lots of people to support your idea because it was already done >10 years ago and basically every browser/web server supports it.
Some reasons client certs aren't more widely used boil down to:
- People like passwords. In particular they like forgetting them and then having friendly people assist them to get it back. Client certs can support this use case, but only if apps are checking the identity in them and not the key.
- The UI for managing client certs in browsers is pretty horrible. There's little incentive to improve it because of (1).
- Cross-device sync doesn't work very well. Apple are starting to tackle this with their iCloud Keychain Sync service but then of course, Apple has all your keys and you may well just sign in to things with your Apple account (if it were to be supported). Cross-device sync where the server doesn't get your keys is supported by Chrome for passwords, but not client certs, because (1)
None of the above issues have any obvious fix lurking within Bitcoin.