Do you mean getdata? Here is the reason for the 6 new messages:

getseginv,seginv - These are for learning about what segments of a block a node has. Else you could remove these messages and simply have nodes advertise blocks via inventory messages. In this case nodes would have to wait until they had fully received a block before relaying anything. No longer is there a benefit with nodes being able to relay segments of blocks before they have received the entire block.

gettreelevel,treelevel - These are to received a level of the merle tree. Instead you might use get data but gettreelevel is more compact than get data and is clearly differentiates itself as part of the new protocol. Perhaps these messages could include the block headers alongside the hashes and you could request many at once like with the getheaders message? If you skip these messages, then you could verify the transactions at the end but there would be problems when peers give bad segments where data would need to be downloaded again.

getsegment,segment - These are clearly important to request and receive segments for the blocks. These allows for nodes to download arbitrary segments of blocks. The optimum number of segments could be calculated by node software using measurements of download speeds and latency times, the number of connections and how likely redundancy is to occur. If a node is up-to-date and likely has many of the transactions in blocks, it can start asking for the deepest merle level (tx hashes) and ask nodes for segments, avoiding transactions it already has.

I'll get around to doing measurements myself sometime to estimate the benefit of this proposal. It will certainly be beneficial when block sizes reach some size but not much is really known except what can be assumed/guessed.

I should also mention the bitcointalk topic here: https://bitcointalk.org/index.php?topic=103295.0

On 10 Sep 2012, at 19:59, "Luke-Jr" <luke@dashjr.org> wrote:
> 
> Most of the problem with block propagation lies in implementation, not 
> protocol... Distributing missing transaction on an as-needed basis is a 
> possible improvement at the protocol level, but there hasn't (AFAIK) been any 
> research into whether the little benefit outweighs the cost yet. In any case, 
> I don't see why 6 new messages are needed instead of simply adding a single 
> new type to getinv?