The difference is that the decentralized approach would put more control in the hands of the user (so they either take care themselves or hire someone to take care for them). If they want to.
"Address is not a private bit of info" - it's person and context dependent. Some people consider their name a private bit of info in some contexts... And yes you have to send the shipping info to the remote party to ship you stuff. But they do not have to keep it neatly packed one select away.
I still have a difficulty understanding how the "random session-id" will solve the problem of privacy. All I can see happening is one more level of indirection, that will cause the creation of the frameworks to re-collate this back. Because this is a functionality that is needed by the developers. And once you have the commonly available code, you're back to previous stage - except with an additional pile of code to debug.
I'm not saying all of this because I think we should stop trying. It's just that I can't see how the cost of uplifting the entire internet infra (the code required for this functionality will surely be much more storage than the cookies over my lifetime) and the cost of having the programmers support both models for the good chunk of future (hello, IE6 users, I am looking at you! :-) justifies the incremental feeling of security that this gives.
edit: re. sending the data to the trusted server: sign with your client key a "request for data" together with the manifest of the addresses that the server can plausibly have. Then when the server needs the data it can present this request to your UA and get the data. Yes, the server can be hacked and this data can be siphoned off. But then the attackers get the [timespan of the breach] worth of user data, and not the entire DB.