Earlier quoted context omitted.
"Why not just...?" I enjoy that you offer up a quite complex, confusing, often insecure, and error-prone methodology with this phrase.
How is sending a user an email complex, confusing or error-prone? As for security, given that an account can already be accessed if one has access to the holder's email (which is the case for any password reset flow relying on email), this is no more insecure than the current state. Seriously, this sort of thing is not complex, not at all .
- I'm logging in from a new computer. Maybe a computer I don't trust enough to log in to my email (which controls nearly everything, as you note). Not all services are that important or need the same level of care as email.
- I'm a user that has greylisting enabled on my mail server, potentially delaying the email for several minutes.
Confusing:
- I'm a user that has never seen/used this authentication workflow. While user/pass is annoying, it is widely understood. Sometimes "ease of use" is really just "what I'm used to". Thanks to facebook and Google authentication, the "Login with..." button is now "what I'm used to". I've never seen the authentication method you've described in 20 years of web use, except as a password reset method.
Error-prone:
- Implementation would have to be done by me on all of my sites. There is no off-the-shelf plugin for this for Drupal or Wordpress or Mediawiki, which run 90% of the websites I am responsible for. I could develop it but I am certain I would make mistakes in said implementation. I should be clear that I think any form of authentication is error-prone, unless it's already written and well-tested. User/pass and optional email is already written and well-tested for every site I maintain.
Security:
- It forces login to email to login to your site. This increases the risk of a user logging in from an untrusted computer or in an untrusted location to an incredible degree.
- Also, one can easily add security questions, or other second factor, to a password reset form, to make it more secure than your solution. Password resets are rare; happening every year or two, most likely. Logins are daily. One cannot impose those security questions on daily login form without paying the same annoyance price as user/pass (higher because it is unfamiliar). Cookies can mitigate this somewhat, but it doesn't solve multiple devices, and security-conscious environments that don't maintain cookies on logout.
If you believe this is an acceptable workflow for authentication, I won't try to stop you. But, it simply isn't a solution for my sites. I don't like user/pass, and I want something better, but I don't believe what you've described is something better. It's a neat idea, but not a solution to logins.