There are apparently some timing analysis attack vectors that I2P and Tor are vulnerable to, and because they are used for browsing the web and similar interactive activities, it's not really practical to add any delays for them. But would adding some random delay in every masternode before it passes the message forward make the timing analysis harder? Or would the delay make the operations take too long? Maybe it could be optional, and the option flag encrypted in together in the message layers.
The masternodes' intercommunications are the noise that TOR/I2P lack. In fact, it's overwhelming noise. It's a Signal to Noise ratio of 100:1 at least... Whereas TOR and I2P have none because their non-incentivised volunteer network would collapse (which already barely works) if they added even a tiny amount of noise.
This gives DRK it's own network of essentially identical function which Evan can tinker with and fix/alter at will, instead of relying on some other project to do it. Both of which have no done it...
Manly. It will be a ton more work to replicate that which is already out there, but Evan needs to take these matters into his own hands sine EFF and the I2P people can't seem to make any progress on their flaws.
It's just a bonus that there will be tons of traffic between the masternodes already, thus, creating the delays/noise/obfuscation. In fact. so much noise/obfuscation that delays will be unneeded. There will be no way to know if the message was from masternode to masternode for normal mixing and simply comms between masternodes, or if it was a send, or anything else a masternode might do in the future. Oh, and it's incentivized... People have an actual reason to do it and get paid to make sure it doesn't suck, ahem, TOR...
And now you are starting to figure out the masterplan and why it's called darkcoin...
Jeez... I knew this 4 months ago... How can people be so slow?
) 
seriously! It is called the internet