Unit costs don't work at small scale. For one thing, there's no single ideal unit: In reality, it's a multidimensional space. If you charge by unit bucket size the folks who constantly churn their files may eat you alive with bandwidth charges; if you charge by unit bandwidth folks may upload great gobs of data; if you charge for
both bandwidth and storage people will get mightily confused and will tend leave your product for a competitor with a more predictable pricing model. ;)
Costs are also nonlinear. The most nonlinear are support costs. You may pay as much to support the user who pays $1 for your service as the user who pays $100. (Unless you keep a meter running and charge by the support-minute, which makes customers very unhappy.) And in practice it's even worse than that: Anecdotal evidence suggests that the customers who are obsessed with saving money cost more to support.
And let me emphasize that costs aren't even the key issue. Engineers tend to forget this, but the price of a product need have little to do with the cost of producing it. Products should be priced based on value to a customer, and that doesn't scale linearly either. The first few hundred MB of Dropbox are the most precious of all, partly because that's enough to sync my most critical and frequently-changing files, and partly because it includes the installation and setup overhead (and, probably, most of the support costs). Then the next few GB is somewhat less precious. By the time we reach a 49GB plan, the value-per-GB is significantly lower. I don't have 60GB of important stuff. Moreover, Dropbox is significantly less convenient when shlepping around huge amounts of data, because it's not magical: It takes time to sync all that stuff over my lame-O cable connection.