This feature might also help with anonymity. Open relay nodes could configure a JSONRPC proxy to allow only this one API. Those wishing to spend anonymously could make a single API call to one of these open relays. A single JSONRPC call is much faster than becoming a full peer in the network, so Bitcoin payments could be quickly spent when driving past an open wifi network.
Couldn't this similarly be used for PoS transactions? For instance, you walk up to the cashier in a 7-11 to buy a candy bar. You pull out your phone, but you normally will have to wait 20 seconds for it to find peers and connect to them. Instead, the store's BTC-processor has a small wifi antenna with restricted network "BTC" -- you can instantly connect to it and send the tx to the 7-11 computer which will broadcast for you (assuming you have enough balance in your wallet already). Also, the 7-11 can be guaranteed to see the tx first, instead of having to wait for it to propagate around the world.
I guess all of this has to be considered in the context of: "is there a problem with accepting 'side-channel' tx-data?" I could see an attacker figuring out how to flood/DoS your client by throwing millions of tx's through the side-channel (if they can access it), but perhaps that side-channel can be treated just like another peer and cut-off if something suspicious is detected. I don't see any obvious reasons this would be a risky feature to add.
Alternatively (on the topic of non-instantaneous tx broadcasting)... what percentage of the "networking engine" would you need implemented in order to initiate a "light" connection to bitcoind through localhost? If tx-broadcasting is all I need, then I bet I could implement only a small subset of the networking protocol and still get bitcoind to accept my tx. It looks like I'd only have to implement a few messages for network version exchange, inv msg. I could skip bootstrapping/IRC, flood detection, peer DB building, etc.
