That was a bigger discussion when Facebook did it back in the days and there's really no clear reason for and against it. In the end it mostly boils down to "regular people were educated that https is needed, so it's better to just keep doing that instead of explaining Tor to them". Which is a fair point I think.
There's an annoying practical reason to use HTTPS on Tor: some browser features are gated on the page being served from an HTTPS origin. Some of them (like geolocation and payment requests) are likely to be irrelevant to most Tor users, but others (like HTTP2 and Web Crypto) are more generally relevant.
Mind you, most of these TLS-origin-requiring features are only accessible through Javascript APIs — and so won't be used by any "zero trust" Tor hidden services
(which must assume the client's Javascript is disabled) anyway.
AFAICT, the one thing you get from using TLS, is a kind of redundant defense-in-depth to the site being taken over: to successfully pose as the site, the attacker would have to obtain both the Tor daemon private key, and the TLS private key. If the Tor session and the TLS session are each terminated on their own middlebox with separate security (or if e.g. the Tor privkey lives in memory on the machine, while the TLS privkey lives inside an HSM attached to the machine), then it becomes harder for anyone — even a state actor — to commandeer the site.
Also, the TLS cert would be signed by a CA, and so that CA can independently determine that the site has been commandeered and revoke the cert. (Not that I expect a CA would actually do this in a timely manner if the commandeering is done on behalf of a state actor — but that's more a fault in our current CA system than a fault in the logic of X.509 trust infrastructure itself.)
https://blog.torproject.org/facebook-hidden-services-and-htt...