On the surface yes. In practice, it's more like email + whatever kind of security system your email provider has set up to verify its really you.
I.e. try to log into a gmail account from a new machine in an unfamiliar location, even if you know the password and can receive SMS codes.
So right now, I'm more worried about getting locked out of a mail account than that someone else could take it over.
As for unencrypted SMPT, there is SMTPS [1]. I'm not sure if this seever supports it, but I'd assume it would be a basic requirement if you want to communicate with real-world mailboxes and not instantly flagged as spam.
just because email is often the defacto identity on the internet doesn't make it a good idea (bandwagon fallacy). i don't consider email tokens to be a serious form of authentication. unless you send the user their authentication secret with data encrypted by the user's public key, i strongly recommend against any use of email-based authentication.
* there are a huge number of middlemen in emailing that you have to trust. the sending email provider, the receiving email provider, ISP, email client, the device the client resides on. and everyone else in between.
* unless you're just hosting an email server on your local network, starting up an email server that can successfully get its messages across the internet to your intended recipient is an extremely high barrier.
email is an extremely error-prone protocol. there's lots of reasons that government/health organizations don't send you personal private information by email and instead send you an email that says to come log into their secure platform to view the private information.
There are mitigations for these security issues. The most important is that you only email the user a random code which is bound to the browser login attempt session. The user is required to enter the code they received in that session. This removes the need to trust any of the parties you listed.
you still have to trust the client device. but i guess if someone else is there you're screwed anyway.
also, email has a potential for a big delay. a lot of times people need to log in quickly. email doesn't always reach the destination in a timely manner.
The UX challenges are real, no doubt about that. That's actually one of the main reasons I started down the OIDC rabbit hole. I was using only passwordless email logins on my services, and wanted to provide my users with the UX of social login without forcing them to give up their privacy to ad companies.
