I've been on the side of advocating for it, but the other side isn't making an obviously ridiculous argument. The onion protocol itself negotiates an end-to-end cryptographic session, authenticated by the onion site's public key, between the onion site and the end user. There's not cleartext traffic sent between a Tor exit node and the onion site or anything!
My argument in favor of TLS to onion sites was that, at least as of onion protocol v2, the cryptographic session was not itself TLS, and its security and threat model hadn't been as extensively reviewed as those of TLS. So it might turn out that there was something suboptimal there that the rendezvous server could then use to perform a sophisticated cryptographic attack.
I don't know if this is still true of onion protocol v3 or if the client-to-onion-site session is now also based on TLS.
https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/r...
I think the main question would be: are there cryptographic attacks that a rendezvous server could do that wouldn't work against TLS?
For connections to the clearnet it was always highly recommended to only use TLS and recent Tor browsers have now finally enabled https only mode that displays a big warning if you try to connect to a http server.
Having a bunch of Tor site certs in your MacOS keychain has its own issues, so what is really needed is a way for Tor browsers to accept those certs directly without using the OS trust stores. The current practice of authenticating the remote site by PGP signature would remain more or less the same - you just wouldn’t have exit nodes sniffing traffic.
I’m also convinced that the whole reason Google has pushed TLS so hard isn’t some noble quest to protect people’s privacy and freedom of speech - it’s more to keep people from blocking their advertisements, which isn’t nearly so sexy an argument, but it has brought good benefits for a lot of people.