I’ve been involved in several discussions about this issue on the tor-talk mailing list. There are some good reasons to try to run HTTPS to Tor hidden services, if possible. One is that the cryptography currently used with hidden services, although it is end-to-end, is somewhat out-of-date; the cryptographic algorithms and parameters used in browsers’ TLS implementations are more in line with current best practices. Another is that some browser policy mechanisms are active for HTTPS but not for HTTP; Alec Muffet, who was the main person responsible for the official Facebook Tor hidden service, has described some of those considerations in posts at
There are other logistical problems with issuing certs for .onion names which have to do with the CA/Browser Forum’s rules. In my understanding the biggest concern is not exactly “how to validate” these names, but rather how to guarantee that ICANN won’t create a separate “.onion” DNS domain, or that users won’t create internal “.onion” domains for their private intranets, which would result in a potential ambiguity about which site a particular cert was meant to refer to. Hopefully a way will be found to guarantee that the top-level domain “.onion” is never used in the domain name system, which will make its meaning unambiguous and reduce the concerns about having certificate authorities issue certificates for names within it.
Because of these concerns, Let’s Encrypt will have to wait and see what the process in the external entities like IETF and the CA/Browser Forum comes up with. There may be opportunities for interested people who are familiar with some of the technical and policies issues to get involved in the IETF efforts.
As @jsha said, Let’s Encrypt does not have the capacity to issue these certificates now, and we’ll have to examine the issue further in the future, hopefully following a clear statement from Internet governance entities that “.onion” should be reserved for Tor hidden services.