I think that there are quite a few reasons why email attestation has not caught on yet.
- First reason is exactly what you mention; that people have an easier time remembering a password rather than carrying a key around. However, the key issue is generally also there in BitCoin (unless the user uses a broker, which have proved to be bad, time and time again). Still, as we have discussed in here and as we are trying to develop with the threshold backup service, this issue can be mitigated in a secure way.
- Since people are still using BitCoin but not email attestations, issue 1. cannot be the only explanation for why it has not taken off. Another reason can be that to use email attestation every provider a user wants to use its attestation towards will need to add code for support for this. There wasn't really any alternative before BitCoin, whereas for email attestation we now have different flavours of Single Sign-On that almost does the same. By almost I mean that a Single Sign-On IdPs are expected to have knowledge of, and verified, a user's mail. Although this is not always explicit.
I think what you are considering to solve here is very similar to some of the things we have tried to solve with the PESTO protocol (and the Olympus project which it is part of). That is, to provide a secure Single Sign-On mechanism, linked to an email address, but not necessarily involving all the sign in and account aspects. That is basically what happens in the full Olympus framework with the PESTO protocol since an IdP has an account associated with a user. This will in practice involve an email and a public key which we can assume the IdP has verified. When the user authenticates it reconstructs, temporarily, its private key, which it uses to sign a nonce (to prove that it could restore it) and returns this to the IdP. The IdP then constructs a token, which can be a standard SAML or OpenID Connect token, that the user can pass on to a service provider. This means that the service provider gets a proof that the user owns a given email, but because of the distributed nature of the PESTO protocol, the IdP is not able to impersonate the user. Furthermore, given that this already is based on a standard it seems that it can prevent the adoption issue.