Linden Lab is in the 3D hosting business. While things like megabytes (either for disk space, or for bandwidth calculations) make sense for 2D hosting (anybody does have the idea that an image will take more space than words, so one understands that one should be charged more for many images than for a bit of text), for 3D hosting, other measures have to be employed that are simple, easily visualised (as 3D is such a visual medium!), and abstract enough to make some sense.
"Land" is a cool first approach, because iRL, we can envision easily that a bigger parcel should cost more than a smaller parcel. However, unlike what happens in RL, an empty parcel in a 3D virtual space does not take any resources (or only minimal ones). A small parcel crammed full of buildings does consume way more than a large one which is completely empty.
So "land" is not a good analogy. Actually, the very old users of SL remember that at the beginning, land was not parcelled. You paid for prims instead (one prim costed L$1 to rez), since the most important resource in SL are textures  they're the ones filling up the databases (object data is relatively small).
On average, every prim has 7 faces (yes, even "tortured prims"), which can mean up to 7 textures to download. It follows that tying prims to textures is a rather good metric: more prims mean more textures, and, although a tortured prim means more polygons (and more client-side rendering), the number of textures to be downloaded is the same. So, from a [i:286n9nl2]server[/i:286n9nl2] point of view, a prim takes always the same amount of data to transmit (which is negligible), and since it has an average of 7 textures tied to it, one can pretty well make an equivalence between prims and textures.
This is from the server's point of view; naturally, from the point of view of the client, one heavily-tortured prim "costs" much more to render (more polygons!) than a simple cube with blank faces. Still, for LL's core business (hosting 3D content), that is irrelevant  it has only relevance in the time to render a scene on the client, not on the effective cost of storing and transmitting the relevant data (prims and textures). Also, no server CPU is required (or server memory) to store complex prim data; a simple cube takes as much a share of memory and CPU than a very twisted prim with hundreds of polygons. This is the beauty of the prim-based system (unlike meshes, which are used almost exclusively on most other 3D platforms)  it actually follows a rather simple model, and one that ties in pretty nicely with 2D hosting (ie. calculating hosted space in MBytes and traffic generated in bandwidth).
What Linden Lab did was tie a "physical" measure of effective disk space (stored textures and prim data) and potential bandwidth (assuming an average viewing of a certain area  an empty sim does not consume outgoing bandwidth, from LL's PoV, while a busy sim will be always consuming bandwidth) to a RL measurement which makes more sense for us humans: land. So, tying land to available prims is a rather good compromise. One can naturally envision that bigger land means bigger buildings and thus more textures, so you should pay more for it.
A mechanism where prims are not tied to land is harder to enforce (as said, LL used that approach in the very beginnings of SL, where you did pay for rezzed prims, but not for land...). This is because that people can upload textures (and you could pay LL a monthly fee based on how many textures of yours are in their databaases) but they might never get used; on the other hand, someone who uploaded a very popular texture might get it being used by thousands of users. The alternative would be to charge for visible prims (as before), but don't tie it to land  but if LL abandoned that approach 3 years ago, it was certainly for a very good reason!.
So pay-per-texture is hard to enforce (and probably unfair  why should a popular texture be penalised?? This would discourage good artists/texturisers to produce them...), and a different mechanism would have to be employed. I think that the hardest bit to implement in this economy is how to differentiate use [i:286n9nl2]in potentia[/i:286n9nl2] and real use. You can have huge amounts of prims in your inventory; but if they're not placed in-world, they just consume tiny amounts of info (ie. just the prim descriptions, which are compact and small); once you place them in-world, they only consume bandwidth if someone sees it. In SL, truly, if a tree falls without anyone looking at it, it doesn't make a sound 
Also, a highly primmy building with huge textures, that nobody sees, consumes nothing; a blank cube which is seen by 40+ avatars, 24/7, consumes an incredible amount of bandwidth! So clearly the method that we currently have is far from perfect  it works well for averages, but not for the extremes.
Eventually I could imagine than in the future the notion of dwell could be "reversed", ie. popular places, since they consume more bandwidth, would cost more. However, this is totally contrary to the spirit of LL, which rewards (even if indirectly) the places that attract more people, and thus encourages builders/texturers/event hosters to be creative in the ways they get people together. "Taxing" them would cripple the whole concept.
In conclusion: I don't think that a future SL (as long as it's run by LL!) will get us an alternative to the land-prim-texture model. Even if prims get replaced by meshes, there will be a similar land-mesh-texture model as the basis for "scarcity of resources". We might need to look towards other platforms to see different models; for instance, how will you pay for access to a OpenCroquet server? This is somehow a problem that the OpenCroquet promoters rarely discuss, since it's supposed to be a "free platform", with "access for free", and "someone else" paying for the costs of hosting, bandwidth, etc. I imagine that if someone would host a paying model of OpenCroquet, they'll do it the traditional way: pay per MByte and per traffic like on a "normal" 2D web server, and get rid of abstract concepts.
But I happen to [i:286n9nl2]like[/i:286n9nl2] the abstract concepts, since they make a whole lot of sense for this "metaverse thingy". Sure, they need some polishing  but what doesn't in SL? 
