2 key things highlighted in the post though:

1. The trade-offs you take are entirely dependent on the type of web app you have and there isn't really a one size fits all solution (nor should there be). If you are having a banking app vs a newsletter subscription, of course the solution would (and should) be different. You can always supplement the email magic links with 2FA based on "something you have" like SMS, TOTP authenticators or WebAuthn. Just like you can supplement traditional un/pw auth with extra factors...

2. The encryption argument is factual but completely irrelevant if the comparison is really between a magic link flow and a password reset flow, which pretty much every site has to deal with. Magic link flow would give 'at least' that amount of security without the problems of passwords being phished or brute forced. This is true whether are not the email is e2e encrypted or not. Recovery mechanisms for some reason tends to get overlooked... and email is by far the most common recovery mechanism present in the internet today.

UX is arguably a security concern. Poor UX impacts availability of the service, and availability is definitely a security concern. It can also tempt users to bypass security mechanisms if they have poor UX, often leading to worse security than before the mechanism was added!

So while it's true that most SMTP connections are encrypted, that doesn't mean anything unless the endpoints are enforcing trust on each other which mostly they're not.

I have no certainty at all that any of those free providers use encryption at rest. How would they mine the messages for data to sell? And, cloud compute is expensive, and disk encryption takes more CPU cycles. Why would they spend that money? SMTP connections are more visible so it makes sense to use that from a marketing standpoint.