This seems like a relatively small vulnerability in practice.

But it could be mitigated by "click the link and enter the one time code we gave you at sign-up time". Too much friction? How about "click the link on the same browser you used to sign up, and we'll verify that using a cookie we just set" - functionally equivalent and probably works for 90% of users while the rest can fall back to the one time code.

I've seen a handful of sites do something like this in practice. No idea why it's not more common: presumably most people don't roll their own verification process so if some major web frameworks adopt it we'll eventually see it more widely.

> presumably most people don't roll their own verification process

Oh boy. Auth is that thing that looks so easy because you just need to store an md5 password to feel like hackerman. If people actually used existing solutions, web logins wouldn’t be in such dire conditions.

Allowing password reset requests (or activating the account in full) before the email is verified, so that I can reset the password and take over the account, means that the holder of the email prevails over the password holder: a severe protocol design error, which can be made even worse by accepting payments before the email is verified or by restricting account creations attempts.

Not all careless stupidity should be attributed to the website admin, however: assholes using random email addresses and phone numbers deserve to be punished, and knowing one's own email addresses is a basic literacy requirement.

or just make a verified email address part of the required sign-up flow. No click on registration link, no further access to account.

Compared to the current status of doing nothing, where the malicious recipient has their email associated to the account of some other person without even having to click a link?

It's not the account of some other person. They can't use it because they can't verify the email to create a password.