The data needs to be stored somewhere. In their implementation they in effect use bit.ly as the hosting provider for the data by shortening the url's, so while it's a fun little experiment, it boils down to a content addressable system. We already have good examples of content addressable systems. Git for example is built on content addressable storage.
It also assumes that there's no limit on URL space that bit.ly provide. Tomorrow they could just max out the "long_url" field or whatever they call it to just accept 1500 chars or something
"Storing a document in a URL is nifty, but not terribly
practical. Hashify uses the [bit.ly API][4] to shorten
URLs from as many as 30,000 characters to just 20 or so.
In essence, bit.ly acts as a document store!"
While the HTTP specification does not define an upper limit
on the length of a URL that a user agent should accept,
bit.ly imposes a 2048-character limit.
