TOR's hidden services are an extremely cool feature.
Not because people can hide their illicit websites (the Warez community
managed to do that decades before), but for other reasons:
.onion addresses name services, not host interfaces. Tying interface
addresses of hosts to names and re-using them in URLs to point at services is a misdesign which leads
to such kludges as the
Server header in HTTP/1.1 where the application
transmits which name it was using when initally connecting to the service.
So URLs map services to hostnames which map to IP addresses which have interfaces which have bound
services which get the unresolved
names again on the application layer to find out which service was actually addressed.
This makes it very complicated to move a service without fiddeling with DNS.
.onion name does not have to ultimately resolve to a globally visible interface address.
Instead it identifies the tunnel-entry for a service which can be moved from machine to
machine as long as the hidden_service configuration is carried along.
.onion addresses deliver what
https URLs failed to,
namely mapping public keys to services uniquely.
There are no multi-rooted hierachies of CAs behind the name-to-key bindings, no obscure
ASN.1 based certificate schemes. An
.onion address uniquely and automatically
identifies the service with the public/secret key pair involved in the key exchange.
There has been at least one attempt to build something similiar into IPv6 addresses
(RFC 3972), but implementations
are either missing or hidden in the darknet.
And because connections inside
tor network are always encrypted, one could even safely run a telnet daemon inside
a hidden service.
As a result of Secondly, Thirdly,
.onion addresses are a barrier-free global namespace, without
absurd fees charged for bits in config-files, trademark disputes and the like.
I run at least one hidden service on each relevant machine to provide a MITM-safe entry point to services.