As some people said, another aspect of this project is increasing the 'availability' of hidden services.
That is, increasing the number of nodes of a Hidden Service so that even if one is down, the rest can still handle clients. This is not something that application-layer solutions like HAProxy can solve.
This even has security implications for Hidden Services since DoS attacks can lead to privacy attacks. For example, if someone suspects that a Hidden Service is hosted on a specific IP, they can shut down the IP and do a confirmation attack by checking if the HS is reachable anymore. If it's not reachable, chances are that the suspicion was correct.
If we could somehow allow multiple nodes to handle introductions and rendezvous requests, we might be able to make HSes more secure against DoS confirmation attacks like the above.
Unfortunately, this doesn't seem easy to do properly [0]. And of course, an attacker can still do confirmation attacks after the rendezvous is done, by sending specific amounts of data to the HS and checking the network of the suspected IP for that amount of incoming data...
[0]: For example, the proposed "scalable HS" solutions allow multiple nodes to handle introductions for an HS, but in the proposed designs the same node that handles the introduction is also the one that handles the rendezvous. If an attacker suspects a specific node to be part of an HS, she can do an introduction to it, then DoS it, and see if the node ever appears in the rendezvous point. If it doesn't, then the confirmation might be successful. There are probably even more subtle attacks that an attacker can do if she wants to do a confirmation attack against an HS node during the introduction or rendezvous steps.