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.
