For a C&C server, you want to achieve the following characteristics:
The infected system must be able to talk to the C&C. This entails getting some data out of the machine, through whatever network access it has. The easy case is when the machine has full Internet access (possibly through some NAT); however, there are networks (especially in business environments) where machines have only local addresses, there is no NAT, and outbound communications must go through a HTTP proxy. Possibly, the proxy will need some authentication, that may be automatically provided by the OS (Windows...) provided that the OS libraries are used to do so.
Thus, HTTP increases the probability of succeeding at connecting to an external server, whereas IRC cannot really handle the "proxy only" case.
On the minus side, HTTP is a client-driven protocol, so the infected machine must "poll" the server (issue requests regularly); it cannot simply wait for an incoming command. This regular activity may allow for easier detection of the infection, and will also increase bandwidth requirements for the C&C, especially for large botnets. IRC would be lighter in that situation.
You want the data transfers to be undetected by the network administrator. Such sysadmins tend to strongly react to any network activity that uses the traditional ports for IRC (e.g. freenode uses 6665, 6666, 6667 and a few others). There again, HTTP will be more likely to "fly under the radar".
Plain HTTP requests may be inspected by nosy firewalls. HTTPS may help you here; decrypting HTTPS requests requires installing and maintaining a custom certification authority that produces on-the-fly fake certificates for contacted Web sites. There are appliances that offer that kind of service, but this is not yet fully widespread.
You want to hide the true C&C server whereabouts. If you have a large botnet, then it is a certainty that some sysadmin, somewhere, will notice something fishy and try to guess where the C&C is. HTTP requests require the client to know the target server IP address. On the other hand, with IRC, the infected host would connect to a nearby "honest" IRC server, and, by the magic of data flow between IRC servers, the data may reach the C&C wherever it currently hides.
For a more complete solution, you would like the C&C to be hidden as a Tor hidden service. Note that the true IP address of a hidden service remains hidden only as long as the assumptions behind the onion network theory hold, in particular that the "uncorrupted" onion routers remain a large majority. Whether this is true in practice is anybody's guess.
A really efficient botnet would be structured as an old-fashioned spy network, with decentralized cells; botnet machines would not know the C&C address, but merely how to talk to the other machines in the cell, as well as one or two machines from other cells. Messages would then be broadcast by hopping from cell to cell. That kind of structure requires a lot more thinking at the design phase, but would be a lot more resilient to dismantlement by law enforcement forces.
(Fortunately, ill-intentioned people who want to run botnets are no less lazy and incompetent than the rest of the World, so well-designed botnet structures remain a rarity.)