If text messages are not encrypted end to end, why is everyone still verifying accounts with them?

The reason it persists is a straightforward and legitimate trade.

Coverage is universal. Every phone can receive a text. No app, no smartphone, no installation, no account, no battery-dependent hardware token. For a service with a hundred million users of every technical level, nothing else comes close on that axis.

It is enormously better than nothing. The comparison people make is against an authenticator app, and by that standard it is weak. The comparison that matters to a large service is against password-only, and by that standard it eliminates the entire category of credential-stuffing attacks, which is the volume threat.

Recovery has to work for ordinary people. The alternatives fail badly when a user loses their device, and a security control that permanently locks out a meaningful fraction of users is not a viable control.

So it is a rational institutional choice that is simultaneously the weakest option available to any individual user who has a better one.

Knowingly accepting it, and the reasoning is more defensible than it first looks — though the conclusion has shifted over the past decade.

Worth correcting one detail first: over the air, mobile traffic is encrypted between the handset and the network on modern generations. It is not broadcast in the clear. What is true is that the operator sees the plaintext, and that the signalling protocols between operators were designed for a small club of trusted national carriers and have not aged well.

So the realistic attack is not somebody with an antenna near you. It is an attacker with access to interconnect infrastructure, or far more commonly, a phone number transferred away from you by social engineering the carrier's support desk. That last one requires no technical capability at all and is how the overwhelming majority of real cases happen.

That is the honest risk profile: not broken cryptography, but a recovery channel whose control depends on a customer service process.

For your last question — what to use where you have a choice — the ordering is fairly settled:

1. A hardware security key or a platform passkey. Resistant to phishing by design, because the credential is bound to the site and cannot be handed to a lookalike domain. This is the only option on the list that survives a user being tricked.
2. An authenticator app generating time-based codes. No carrier involvement, works offline. Still phishable — somebody can ask you for the code — but a large improvement.
3. Push approval in the service's own app. Convenient, and vulnerable to approval fatigue if the prompts are frequent.
4. Text message. Better than nothing, and the thing to move off first.

One important extra step people miss: enabling a stronger factor does not help if a text message remains a valid recovery path. Attackers go around the front door. Check the account recovery settings, not just the login settings, and remove the number where the service allows it.

Worth adding the protective measure on the carrier side, since that is where the realistic attack lives: most operators will let you add a port-out PIN or a transfer lock to your account.

It is a short phone call, it costs nothing, and it directly addresses the failure mode that causes essentially all real-world cases. If you are going to keep a phone number as a factor anywhere — and most people have to somewhere — that call is the highest-value ten minutes available.