Hidden Service authorization is a pretty obscure feature of HSes, that can be quite useful for small-to-medium HSes.
Basically, it allows client access control during the introduction step. If the client doesn't prove itself, the Hidden Service will not poroceed to the rendezvous step.
This allows HS operators to block access in a lower level than the application-layer. It also prevents guard discovery attacks since the HS will not show up in the rendezvous. It's also a way for current HSes to hide their address and list of IPs from the HSDirs (we get this for free in rend-spec-ng.txt).
In the current HS implementation there are two ways to do authorization: https://gitweb.torproject.org/torspec.git/blob/HEAD:/rend-spec.txt#l768 both have different threat models.
In the future "Next Generation Hidden Services" specification there are again two ways to do authorization: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/224-rend-spec... One way is with a password and the other is with a public key.
I suspect that HS authorization is very rare in the current network, and if we believe it's a useful tool, it might be worthwhile to make it more useable by people.
For example, it would be interesting if TBB would allow people to input a password/pubkey upon visiting a protected HS. Protected HSes can be recognized by looking at the "authentication-required" field of the HS descriptor. Typing your password on the browser is much more useable than editing a config file.
Furthermore on the server-side, like meejah recently suggested [0], it would be nice if there was a way for HSes to be able to dynamically add/remove authorized clients using the control port.
[0]: https://lists.torproject.org/pipermail/tor-dev/2014-October/007693.html