The push for TOFU really only began about a year after the protocol was first designed, as it was deemed "too difficult" to obtain a real certificate, even from Let's Encrypt.

On the other hand, those that want something SSH-like for the web have something to point to as an example, as well as those that don't think SSH-like for the web is a good idea as an example.

TLS gives you protection against casual eavesdropping or tampering.

Of course, self-signed certs + TOFU theoretically allow a third party to insert itself as a MITM at the first connection. This needs a lot of tracking and preparation beforehand; no adversary of this caliber is going to be interested in Gemini content.

Adversary of what caliber? All they have to be able to do is redirect a host (for instance by poisoning a local DNS lookup); the actual exploit is trivial. They're self-signed certificates; in the absence of a "TOFU" scheme that doesn't yet meaningfully exist, they provide no security against attackers willing to spoof DNS responses.

"TOFU" is also a truly abysmal fit for any application with a mass audience (at any given time, a huge percentage of your inbounds are going to be people making their first request, all totally open to attack --- contrast that with SSH, where you make first contact with a host on a new machine fairly rarely).

The whole point of TOFU is the user doesn't manually verify.

That's not really true, though. Like with SSH, the first time you receive a certificate for a server you are prompted to either trust it or not. If you choose to trust it then from that point on it remains trusted unless explicitly removed from the set of known hosts. Of course, the client could just take the option away from the user and automatically trust every host the first time. But then there's even less point in having TLS here.

Even Signal's TOFU method offers a way for users to manually verify that the keys of the people they're communicating with, even though it permits communication from the start without verification.