I found this discussion quite interesting:http://forum.bitcoin.org/index.php?topic=1865.msg116300#msg116300
Visa handles around 8,000 transactions per second during holiday shopping and has burst capacity up to 10,000tps.
Of course MasterCard also handles quite a bit. I don't have figures for them but I guess it'd be in the same ballpark.
I don't believe artificial scarcity is a good plan nor necessary in the long run, so requiring end-user software to enforce these sorts of rules makes me nervous. I don't plan on adding max size checks to BitCoinJ at least, they aren't even enforceable as in future SPV clients probably won't request full blocks.
It seems to be a nontrivial question how to handle as many transactions as needed but still keep fees high enough to make mining profitable. I think it could work without any kind of block size limit, neither fixed nor automatically adjusted:
For miners to store a transaction permanently on disk costs a certain amount of money. They can choose which transactions to accept and which to reject. Usually they will accept transactions with fees high enough to compensate the cost of storing the transaction permanently. Note that under the assumption that prices for storage memory continue to decrease exponentially over time, the cost of storing a transaction forever is finite.
The desirable equilibrium transaction fee (economic efficiency) is reached when to the fee for a transaction is equal the sum of costs it causes for all miners together to store this transaction. The problem with the current method is that is causes a social dilemma in the way that for each miner it is already efficient to include a transaction in a block if the transaction fee compensates only his own cost, not all the cost for the other miners also.
An approach would be to not spill all of the transaction fees of the transactions in the block directly to the miner who generated the block, but is dispensed over a number of blocks n in the future (excluding the block in which the transaction is confirmed first). This means a the miner of block x receives the nth part of the fees of all the transactions in the blocks from x-n to x-1. n just needs to be sufficiently large that the probability that one miner generates n consecutive blocks faster than the rest of the network is rather small (maybe n=2 is sufficient).
Which effect would this have on the incentive for a miner to accept a transaction in a block? Assume the miner in average mines a fraction 1/q of all blocks. It would be efficient for him to include the transaction, if his own storage cost for this transaction is < fee/q as the probability for him to get the 1/n of the fee is n/q.
Of course q is different for each miner. This means mining is only profitable if your q is sufficiently small, or in other words your computing power is high enough. But this problem exists in any situation where storage cost becomes an issue.
As a nice side effect, it would reduce the desire to not continue the longest chain, but to reject the latest block, because there are many transaction fees inside you want to have for yourself. The decision for miners if the accept of reject a block would be purely based on if the transactions in it are 'social', in the sense that the amount of fees stands in a reasonable relation to the cost for the network to store the data. If n would be made large enough, the fees per block would change very smoothly over time, which would also contribute to this effect.