the reason for the more ultrapeer<-->ultrapeer connections and the less leaf<-->ultrapeer connections are because of the amount of traffic and flow-control algorithms of various gnutella clients...

if a leaf has many ultrapeers and sends a message (that lasts for 7 hops) to those ultrapeers, who then forward it to a few ultrapeers and their many leaves, who then forward it to a few more ultrapeers and their many leaves, (repeat 4 moretimes), chances are that sometime along the way, a client is going to 'drop' this message because its handling too much traffic. therefore, it actually lowers the amount of hits you're going to get for that file.

if a leaf has a few ultrapeers connections and sends a message (which now lasts for 4 hops) to those ultrapeers, who then forwards it to many many ultrapeers and their few leaves, who then forwards it to many many ultrapeers and their few leaves (repeat 1 more time), there is a much lower chance that a client is going to lose the message among the traffic.

this also opens the door for allowing one to 'probe' for queries, by first sending a short-lived message and letting it go to the much larger range and seeing if results come back -- if none, or not many, do, then it sends a longer-lived message, reaching further out into the network.

and to help reduce the traffic even further, QRT messages(essentially filters) are forwarded between ultrapeers now (although only checked on the last hop) instead of just from leaves to ultrapeers, ensuring that ultrapeers won't needlessly send message to the many other ultrapeers.

basically, it's a good thing the way it is.