There may be more pressing issues right now, like wallet encryption and backup - but one issue I feel is a major limitation for quite a few use cases is that currently, there's no way of doing automatic recurring payments, e.g. for subscriptions.
Use case (this is just one example): A subscription based game service (multiplayer game). Players subscribe to the service and agree to do recurring payments. With the current client, I don't see a way to do this in any way that's convenient for the player. And when it's not convenient for the endusers, it will simply not be done. Other businesses that could benefit from such a feature would be magazines; for-pay online services (news services, professional networks etc.); support contracts and so on.
So, IMHO, as payments can only really be done from the client, the client needs some sort of subscription / recurring payment management. Basically, all it has to do is check whether there are any open recurring payments and if so, send them out. In case the client wasn't run for a longer while and it missed payments, the system might warn the user. The receiver would need to check if the subscription is still valid by checking whether or not the payment arrived in due time. So, the client would be responsible for sending it timely (one part of the "official protocol" could be: "subscriptions are cancelled by not paying in time"; and previous subscriptions could be resumed by paying again).
If you only switch your computer on every 3 days, you might want to send the payments 3 days early so you don't accidentally cancel one of your subscriptions. If you're away for a month, you might decide to do any upcoming payments for that time period immediately (which means that the receivers must be able to handle multiple simultaneous incoming payments; in other words: when I have a monthly subscription, and I get two payments one would be used for the current month, and the other one for the next).
Still, the greatest limitation of such a system is obviously that it only works when the user starts the client. So it should probably also be available for mobile, and ideally sync between different clients. It should be possible to prevent double-spending via the ordinary P2P-protocol (get the latest transactions from the blockchain, check if the necessary transaction was already done, if not, do it now). There's a little risk for simultaneous transactions - but that can be minimized by properly timing the different clients (e.g. have one client set to 8am, the other to 8pm, so there's 12 hours for the payment of the first client to distribute the transaction).
There might be optional 3rd party services that do the automated payments for you when you're offline (or even in general, if you so wish). Those could charge a little fee on top of the actual subscription rate. It should probably be a hard rule that each subscription *must* have its own receiving address (I think synching payments by receiving address is the most straightforward to implement). Using such a third party service, you could make sure that your local client sends the payment a day early; so usually the service would recognize it's already paid for and not do the transaction (which would save you the transaction fees). Only when your local client misses, it would kick in.
What might be really nice with such a system implemented directly into the client is that you have one central place where you store all the subscriptions you have. And unless you use a 3rd party service, your local computer is the only place where all your subscriptions are stored. Obviously, the client should provide some data with the subscription, like "Website of service provider", maybe even "terms and conditions that apply to the subscription", contact details. Basically, everything that's relevant to the subscription or pointers to that.
While having the currency itself decentralized, it's certainly much more customer friendly when we have all our subscriptions managed in one place (this is also one of the key selling factors for Apple's App Store subscriptions ... but they take 30%, and they all your subscriptions on their servers ... that's the problem when 3rd parties are involved; in the Bitcoin approach, 3rd parties would be completely optional). If there's 3rd party providers handling the payment of the subscriptions for you (as outlined above), there could be a protocol with which you can connect your client to your service provider, decide which subscription they should do, over which time that should work and transfer both the subscriptions and a few BTC so they can be paid for (and the subscriptions could automatically be sent with the "1-day delay" so things work smoothly without having to think of too much complex stuff ;-) ).
My feeling is that this can really be done in a way that makes it very easy and safe for the user, even though there might be quite a bit of complexity going on in the background.
So when this is done right, it could be one more step in Bitcoin taking over the world. While it's obviously possible to implement that as an extension, my feeling is that it would be wise to have this as a part of the "main package" because that way, a standard could be created that other implementations can follow. Ideally, if you change clients, your subscriptions would still work on the new client. IMHO, aside from some other, smaller usability issues and some pressing security issues, that's one "big thing" that could help Bitcoin become interesting for the masses.
There already are subscription services by Apple, and I think something similar is also available for Android (any PayPal also has it), and as a developer I can say: This is really great, I'd love to use it - BUT: I really don't want a 3rd party to take 30% ... and I think there's quite a few developers out there feeling that way, too. If Bitcoin could provide an alternative that just works - OMG, that would rock (admittedly, quite a bit of the infrastructure that Apple / Google are providing would have to be done by the developers in the Bitcoin approach; but saving 30% would probably be worth it in many cases ... even if you'd have to add the "Apple way" as an option to comply with their terms in their world)! ;-)
What do you think?