For users, there's no cost-benefit balance for using bandwidth, only benefit. This leads to inefficient use of what is, at the end of the day, a limited resource. For the carrier, there's every incentive to minimize the amount of network activity, so they can squeeze more users onto the network. It's hard to know how this affects Apple, but is there any doubt that the fragility of the exclusive carrier in their primary market has affected their development schedules and priorities? App developers don't care about bandwidth, except to the extent that they can get their app banned by the carrier if they use too much of it.
Unlimited data plans are not the only factor, but it's no coincidence that AT&T has such poor network performance, doesn't allow tethering etc. This even affects iPhone users in other countries - would the iPhone have supported tethering earlier, if AT&T could make more money from the increased network activity? What about downloading music over the air? Skype?
With a pay-for-what-you-use pricing scheme, the interests of the user and the carrier are more closely aligned. The ideal would be something like Amazon's S3 pricing: based on usage, metered in small increments, and cheap!
Similar behavior was seen when telecoms had to give up on long distance phone charges. And again with text messages. This is just more of the same. And I will tell you why customers won't put up with it - it's very hard for an average person to know how much data they are consuming. They don't want to know either, it's just another thing to worry about.
The point here is that cellular bandwidth is scarce. Apple and Google jump through all sorts of hoops to use less of it, while still providing a good user experience. If consumers don't feel some of the pain of that it leads to real problems. I can tell you that I have much better service here in Canada, with tiered data plans, than AT&T customers do.
As for consumers putting up with it, we'll see. People never had problems understanding how long-distance worked. And charging by the minute seems to be working well for Skype.
Today it's hard to see how much data you've downloaded, but it doesn't have to be that way. I see two causes for this: 1) It's hard to present an itemized bill for data usage the way telecoms have traditionally done for calls. 2) There aren't many tools for monitoring and managing data usage because right now it doesn't matter. Everyone (int the US) has unlimited data plans, so why bother? But these are solvable problems.
That's because a minute of usage for both Skype or long distance calling is easily quantifiable. If I talk on the phone for 10 minutes at a long distance rate of 10 cents a minute, easy, that's a buck.
Heck, it was easy 10 years ago when we had WAP phones that used circuit switched data, because a minute of browsing the web meant a minute of airtime.
But how do you tell an unsophisticated user that given the bit rate and duration of a video on Youtube or song on Pandora, he'll use X amount of data? What is the best way to explain how many web pages or Google maps driving directions they can access before he bumps into the limit? How much data is behind a Foursquare checkin?
Edit: ATT puts per-session data usage on detailed bills (meaning my data bill would be 30 pages long if printed), but its altogether useless at trying to match back to what you were doing when you generated those data usage records.
On the flip side, even as a "sophisticated" user, I can't tell how much bandwidth a given video will use, or how long I can afford to stream Pandora to my phone. But it doesn't mater. My carrier provides an app that I can use to check my usage, and I can see how much I've used as a percentage of my limit. It's easy to get a sense of "been watching a lot of video lately, gotta ease up on that," or, "oops, downloading that ISO over tethering wasn't a good idea." It's not long before you have an intuitive sense of what things cost, in terms of bandwidth. I find I don't have to pay much attention unless I use tethering, but my data plan has 6GB cap.