"Sorry", but you just moved the centralized identity to a different location, you aren't magically removing it: in fact, you can't magically remove it, because there is no such thing as a universal canonical form of identity. If there was, we would just use that instead of all of these more complex forms of identity we build up.

In the case of the e-mail address, you are moving it to the person providing the domain name the e-mail address is on; this is thereby explicitly why I brought up OpenID--which you seem to have totally ignored--as it is also a distributed system but yet it doesn't force the incorrect assumption that Persona does (specifically, that e-mail addresses are canonical identification mechanisms for users, and so nigh-unto encourages opaque tokens to be returned).

Let's put this another way: you seem to believe that there is a way to assign a token to a user in a way that works for them no matter where they are. I believe that that entire concept is a fantasy. In particular, I believe the one that Persona chose, which you seem to want to defend, only works for a very weird subset of users that are technical enough to understand that others make this incorrect assumption, and then organize their lives around it.

In comparison, once you assume that there is no such identifier, you start asking how you federate the choice, and you end up with the idea of "identity providers". However, you now have no stable way of holding on to identity as you change providers. I maintain that is an unsolvable problem, and it should be treated as an unsolvable problem: the concept of an identifier that can cross multiple identity providers is, again, a fantasy.

So the result is that you now have to ask the question of what identifier is used within an identity provider. I maintain that e-mail addresses are a horrible horrible choice, as they are known to be something that the people who provide them are known to reuse, and they are things many users want to be able to change often. Instead, it should be encouraged to make the token entirely opaque, with a requirement in the spec that "this token will never get reused by any other user using your identification provider ever in the future". AFAIK, OpenID states exactly this.

And yet, when I go to log in to a website using OpenID, I can select Google as my authentication provider, and then log in with my e-mail address. Later, when my e-mail address changes, I'll be able to log in with a different e-mail address, and Google will assign me the same OpenID identifier for my federated login with other websites. You end up in a similar boat if you use the various OAuth flows that other companies use, such as with Facebook, then using an API to get the stable identifier (which for Facebook is a number).

Look: I maintain a website with tens of millions of worldwide users, and I only have federated login. I deal with the issues of federated login day in and day out. I deal with users from very diverse user communities, and I see how they treat their e-mail addresses (as sadly, Google will not let you change your Gmail address without getting a new account, so a lot of users are forced into situations where their identification changes when there was no real reason why it should have been required). When I look at Persona, all I see is a support nightmare due to a fundamentally invalid assumption.