$0.15 per GB-Month of storage used.
$0.20 per GB of data transferred.
So, that means Dropbox is going to have to resell S3 at a premium for the added value of these nice Coda-like features. Would you pay a premium for these Dropbox features? Maybe, I don't know.
Also, what's the typical use case? How much bandwidth/storage are people going to consume? Because, if I store 100 megabytes... my bill will pennies every month (going on S3 prices). You cannot transact pennies per user per month. If you could, then you've cracked the micropayments problem wide open. Maybe there would be a base fee? Like $5/month or something. Would people pay that much for online storage?
I think the larger issue is about getting user adoption. It is actually great case to have a situation where users overwhelm your service in a way that it outgrows a system such as this. If he ever gets that large, obviously there will be plenty of people looking to help him figure out how to make the storage portion feasible.
More interesting is the user experience. Creating something users can enjoy, agree with, and possibly part money for is a much more difficult problem to solve than figuring out to make large scale storage cost effective.
I think user experience can and will be duplicated. I did post a link to an SVN front-end that has a very similar interface. Maybe the competitors are locked-in to some bad design decisions and can't quite recreate the same user experience... but that's a little optimistic.
Anyway you slice it, you need to have a profit margin. And with a commodity like storage (and the soon-to-be commodity of online storage), you have to be competitve with market prices. The reason that most YC startups can worry about user adoption is because they aren't tied down to this problem. They aren't really making commodities and the cost of makign the product isn't so suffocating.
That's why Dropbox needs to plan for moving off S3. There is so much innovation in storage backends... so much research to read. Think of Google Filesystem. It makes storage very very very cheap.
Here's a good plan for Dropbox. Use S3 as a secondary solution. The primary storage should be local to them (servers running a filesystem that takes advantage of unique properties of the workload... like Google does). When it fills up, traffic thereafter is handled by S3 instead. Then, they can relax in worrying about and scaling local storage. They can take their time buying more hardware, and rolling out software changes to the storage system. They can migrate the data from S3 to local storage at will. And now, their customers can be charged a flexible price, because they control their own expenses. In other words, think of S3 as "datacenter outsourcing".
But this might be too long-term... it might be something to worry about post-YC.
But I think it might be easy to build a storage implementation that runs local and exposes the same exact interface as S3. And, poof, we just abstract the whole backend away, and just flip a switch when we want to go one way or the other. And it reduces latency. Then you go after zero-downtime data migration from S3 to your local systems... which can be done I think... and I think you would be happy.