Note: I am not associated with the Tor project, just an interested observer. I happen to be implementing a similar protocol for something else.
Because it needs to be resistant to compromised nodes. The reason for this that hidden service connection details (though not the server IP obviously, since all of this happens through Tor channels) are stored in directory servers which are randomly assigned each day. The choices of directory server are derived from a pseudo-random string 
SHA1(permanent-id | SHA1(time-period | descriptor-cookie | replica))
by taking taking hashes of the directory identity details and sorting, and then picking those that come after descriptor-id in the list.
The problem is that a malicious would-be directory can modify its own configuration so that its hash changes in order to gain responsibility for an arbitrary hidden service at some point in the future, since the descriptor-id values are predictable. This doesn't give them complete control, but they could perform DoS and traffic counting.
What was proposed last year, then, was to add a random element to the data being hashed so that it could not be predictable . In order to prevent there being a single point of failure (both from a reliability and security point of view), it was proposed to use a distributed random number generator. The way that this works is that while the master directory servers agree on the list of relays, they also generate a random value and use a bit-commitment protocol  to commit to it before the final value is generated in order that the last server to vote can't just keep generating random values until it finds one that gives it control of a given service.
The way that this happens, then, is that during the first half of the day the directories will include committed values with their votes on the network status. During this time everyone should get a copy of the committed value, which is generated by hashing a random string . Then, during the second half of the day, they reveal their chosen random values. The others can then hash the received value and compare it with what they were given before in order to make sure that they have not changed their random value in response to the other random values.
At the end of all this the revealed values get hashed together in a particular order and the resulting value is published and put into the descriptor-id by server operators and clients. You can't use one of those idQuantique etc. cards and call it a day because there's nothing to stop a compromised server from emitting random values that are favourable to an attacker, whereas this approach will still be unpredictable so long as at least one of the master directory servers is honest and takes part.
 Tor Rendezvous Specification
 Tor Proposal 250: Random Number Generation During Tor Voting
 Commitment scheme