It sounds appealing at first because it flips the trust model... instead of the service initiating contact the user proves control of their email up front That feels cleaner and arguably more robust against certain classes of abuse

But from a UX standpoint its a nonstarter

Youre asking users to

- leave the site/app

- open their email client

- compose a message or at least hit send

- wait for a reply

- then come back and continue

Thats a lot of steps compared to enter email -> click link. Each additional step is a dropoff point especially on mobile or for less technical users. Many people dont even have a traditional mail client set up anymore, they rely on webmail or app switching which adds even more friction

It also introduces ambiguity

- What exactly am I supposed to send

- did it work

- What if I dont get a reply

From the service side youre trading a simple well understood flow for a much more complex inbound email processing system with all the usual headaches (spoofing parsing delivery delays spam filtering)

In practice most systems optimize for minimizing user effort even if that means accepting some level of abuse and mitigating it elsewhere. A solution that significantly increases friction... no matter how principled...just wont get adopted widely

So while the idea is interesting from a protocol design perspective its hard to see it surviving contact with real users