Every release since 0.7 has included performance improvements as a key feature, starting with the very important merging of Pieter Wuille's ultraprune branch. Remember that this time last year we were ridiculing Peter Todd's "keep bitcoin free" campaign to enshrine the 1MB block limit. Even Peter Todd has switched positions on that one, so I think I can generalize to say that we all see the need for bitcoin to scale to higher traffic levels, and identify many outstanding problems to be solved between here and there. But beyond that I don't feel comfortable commenting on the specific positions of individual developers other than myself.
What's wrong with charging a fee for data use is that it does absolutely nothing to solve the problem. Fees go to miners, not full nodes. You don't collect a single Satoshi for running a full node. And until that incentive problem is fixed (it's not clear it can be), scaling bitcoin up means centralization and degradation of the peer-to-peer network, to the point of becoming compromised or unusable.
Please correct me if I'm misinterpreting what you are saying (and ignore the later points of this post if so) - but I understand the current situation as follows:
a) Currently a very significant problem is lack of incentive for Full Node participation combined with simultaneous Network Scaling
b) Counterparty transactions currently take up 5mb of an 18gb blockchain but if use of counterparty and similar protocols increases dramatically the above problem will be exacerbated before it is possible devise an adequate solution.
If I may, I think just as you don't see it as immediately feasible to address Node incentive and Network scaling, phantomphreak probably doesn't see it as immediately feasible to go from a working secure protocol to a not-yet-coded potentially vulnerable side-chain, for the sake of 40 bytes. Still I doubt there are any serious counterparty or bitcoin users that see a positive future where certain functionality exists at the cost of the health of the entire network as a whole.
As a lot of good developments may come from foresight in implementation, and much can also come from necessity - counterparty as a protocol requires more blocks to be functional (i.e. distributed exchange order matching) than simple sends, if the network even begins to be over-burdened it's effect will be felt there first, and I don't think anyone will continue to use something so unoptimized without moving towards a solution. In the short-term I think Luke Jr's proposal is actually a lot more sensible than at first-glance. Yes, in a way it is undermining net-neutrality and may take a large share of criticism for that - but it also provides a method at least for counterparty and mastercoin to switch to a cleaner implementation (the benefit of which is apparent here and now) without making a seemingly irreversible commit to the protocol at the core.
Again if I'm not misunderstanding: the core developers it seems to me are very naturally worried that to implement a large or limitless OP_Return is to encourage other projects to put similar functionality into the blockchain before node incentive and scaling problems can be addressed.
.) 
