If one looks at the bitcoinwatch pie chart, the "other" part of the pie shrank significantly. Since this calculation from reported hashes and global hashrate is rather inaccurate (e.g., due to changing speed between pools and a "luck factor"), I counted blocks solved by pools during 24 h starting 30 May 20:00 UT.
The whole Bitcoin network found 142 blocks. Individual pools:
deepbit: 55 blocks
slush: 22 blocks
btcmine: 18 blocks
btcguild: 12 blocks
eligius: 5 blocks
swepool: 2 blocks
bitcoins.lc: 0 blocks (unlucky day apparently)
total: 114
other miners and smaller pools: 28 blocks = 20%

I do not have some hard data but I think this is an all time low.

What we can guess from this statistics? Well, apparently with current difficulty the variance with mining solo is rather brutal for small miners. Even a few high-end rigs may be not enough to find a block in a week. And it seems people are rather risk averse. I find it interesting that a lot of people spend quite a lot of money on gambling and unfair lotteries (unfair=with payoff to winners less than ticket revenue). Yet Bitcoin, which is a fair lottery (and better than fair, with extra fees in the blocks), has so few players that want to take  the risk.  

Also, it seems that a notion that mining is rather concentrated is not true. Large miners prefer mining solo (we do not have stats for all pools but for those that publish statistics, largest miners are in teens GH/s max). Those big solo miners are apparently at best 20% of the global hashrate and likely less since there are definitely some hard-core solo miners with small hash rates. Therefore, mining income is rather widely distributed. I think it is rather good for wide adaption of Bitcoin. It is also good for safety and robustness of the network (even though it is concentrated in pools). Recent dynamics is for concentration of mining in pools. If it reverses, this may be a signal of a start of mining concentration.

I'm very impressed by the current Bitcoin hashrate, overtaking the fastest supercomputer Tianhe-1A and probably also Folding@Home. For safety, even larger network would be necessary. 

However, at current 2700 GH/s, taking most efficient GPUs at roughly 0.5W per 1MH/s, the whole network needs 1.35 MW of electric power (FPGAs or ASICs that are used by some are more energy efficient but are more expensive and carry larger depreciation cost). With 8-9 blocks/hour, one blocks needs about 150 kWh. This is probably about $15 on average. So if there were currently no block rewards and miners were supported only by fees, a block would have to carry at least $15 in fees if you count only electricity costs or the miners will stop mining. With hardware depreciation that the miners would want to recover and some profit the fees would have to be even larger. With about 15-20 transactions per block (which are mostly free so there would be less of them if there were fees required), one transaction would need to carry at least $1 of fees. This is quite expensive. I claim that the current network size could not be supported by fees only.

More efficient miners would not help much (if at all). More efficient miners would be available not only for the Bitcoin network but also for the potential attacker. The Bitcoin network would have to be always ahead of the attacker. Maintaining such a network will be quite costly. Worse yet, there will have to be constant mining performed while the attacker could just rent the compute time for a few hours to do a >50% attack. Can we really afford it?

Unless the number of fee carrying transactions grows a lot before the mining reward is reduced,  we are going to end up with not large enough and prone to attack Bitcoin network. Or with fees that are hardly better than in mainstream banking.

I haven't seen such a graph, yet. So I made one myself:
http://bitcoin.atspace.com/fees.html

The fees are still fairly insignificant (only about 0.04 BTC or 0.08% of the 50 BTC) but has gone up from zero. The first jump in fees was related to the start of fee inclusion by the Faucet. The Faucet has recently started to group the transactions to minimize the fees but there is a pickup of fees probably paid by 0.3.21 clients (low priority transactions).

I wonder how large will the fees be at block 200,000 when the payout drops to 25 BTC.

I have written a description of the optimal pool abuse strategy (for a single pool) with proofs and calculations. Available here:
http://bitcoin.atspace.com/poolcheating.pdf

If the link does work, use a mirror: http://mining.bitcoin.cz/media/download/poolcheating.pdf

I have started this work some time ago and it is not finished (I wanted to derive the optimal strategy for multiple pools but it's not ready yet) but with jgarzik's announcement of a new pool code, there is a chance we have multiple pools very soon and with multiple pools, pool abuse gets more profitable, and because I realized there is a perfect countermeasure, I decided to publish it now .

For those who don't want to bother reading it, the optimal strategy is to join the pool at the start of a new round and stop pooled mining after 43.5% fraction of the current difficulty of shares was contributed and start mining solo. This strategy will bring 28% of extra income compared to only pooled or only individual mining.

In this thread, the author finds no evidence of massive use of this strategy
http://bitcointalk.org/index.php?topic=2941.0
(I didn't read the paper since I find it strange to ask for a payment for something that may or may not contain anything interesting; and I didn't find any hard numbers in the discussion)
However, I was testing it in mid January with 3-4% of the pool hashrate. It is indeed very hard (at this level it is quite well buried in the noise) in the global hashspeed, but it is possible to detect by the pool operator by checking the payout. An abuser, will have significantly larger payouts in the short rounds than in longer ones.

Concerning the countermeasures. Apart of administrative ones (i.e. banning) which will be difficult if one starts to be more clever: randomly changing switching threshold, contributing all the time with a fraction of ones hashspeed, etc, there is of course a connected method which is will be very hard in slush's implementation. It is also possible to calculate the payout based only on the very recent shares but it only reduces the cheating payout, not eliminate it. However, after reading the recent jgarzik's pool discussion
http://bitcointalk.org/index.php?topic=3078.0
and his "bug", where he only counted shares contributed to the latest block, I realized that such counting is a perfect countermeasure. Since finding a block ensures that everybody else who worked on solving this block wasted its effort, there is no incentive to switching from the pool. If one switches from the pool and finds a block, the pool resets its counter and all the cheater's "unearned" shares will be lost. Of on the other hand, one switches from the pool and the pool find the block, it guarantees there is no individual income after the switching. I'd advice slush and other pool operators to implement this counting. It slightly increases the variance of ones income but it's fair, it's simple and eliminates cheating which with multiple pools can become widespread.

Edit; It won't work, see the further discussion.