Let's say I used my work address to sign into a bunch of stuff, but then I leave my job and I lose access to my email address? Or say I'm migrating from using @gmail.com for everything to using my own domain?
One tradeoff of Portier's approach is that you can't authenticate if you lose access to your email account. This can be a pain in the ass in some cases, but beneficial in others -- pull someone from your company's LDAP and they can't represent themselves with that email address anymore. Tradeoffs :/
User continuity and conjunction (as a user here are three emails that all represent "me"; this one I used in the past but cannot access now; this one is my "primary") is definitely a complicated problem and there are definitely some domains (corporate) that need to be stricter with what they allow than others.
The best argument I found was that all of the major website frameworks in use today (Rails, ASP.NET, Laravel, Django, what have you) provide in the box solutions for user continuity given the existing "standard" of username/password connected to an assortment of email addresses and/or OpenID Connect connections. The easiest way to implement Persona (or Portier) in most frameworks and continue to take advantage of built-in user continuity was as "yet another vaguely OpenID Connect"-like option in the potential giant wall of login brands, which means that it competes with Facebook/Google/GitHub/et al login for mental brand space.
Obviously there is no "easy" answer here, but it would definitely help sell Portier to potential sites if there were some answers. Perhaps some sort of user continuity service (or service options) would be useful as another microservice in a "Portier ecosystem" even if it is just barely on par with the built-in templates of the average web framework today. That could help make it easier to "sell" it as a drop-in replacement for all of the bulky weight of web framework user systems rather than "yet another login option in a sea of them".