- content must be able to move as fast as the underlying network permits. this rules out designs like freenet's and other oblivious storage platforms, as the base case. Like you said, they're just way too slow for most of IPFS use cases. But, these can be implemented trivially with the use of privacy focused transports (like Tor and I2P -- there's actually work towards this and people are getting close), content encryption, and so on.
- IPFS nodes should be able to only store and/or distribute content they _explicitly_ want to store and/or distribute. This means that computers that run IPFS nodes do not have to host "other people's stuff", which is a very important thing when you consider that lots of content in the internet is -- in some for or other -- illegal under certain jurisdictions. Legitimate companies have way too much in their plate to additionally worry about potentially be storing a ton of illegal stuff. For serious companies like Google to use IPFS, we need to have a mode of operation that allows implementations to ONLY move the content THEY want to move.
- Websites/Webapps must be able to operate entirely disconnected -- this means that it should be possible to build applications which create data locally, signed by the user, which can be distributed encrypted end-to-end to other users, without needing to ever touch specific backbone servers. This means users can move the data end-to-end via the closest route possible and in disconnected networks (think users on mobile phones on a plane using messaging webapp or web game and moving the bits over bluetooth or an ad-hoc wifi network. And this also means users in the broader internet do not _need to_ rely on backbone servers -- the model we're going for is that dedicated computers in the backbone CAN of course and SHOULD help, but you shouldn't HAVE TO RELY on them.
Can write more about this :)