I expect at this time bandwidth is the major bottle neck.  At least in the US I think we can expect someone wishing to run a full node to have at least 1Mbps of bandwidth.

All transactions will be first broadcast then transmitted again in a block.  There is also overhead for the inventory notify messages.  I will guess that protocol overhead, inventory and addresses take up about as much bandwidth as transactions so needed inbound bandwidth is about 3x what is needed to just transmit the blocks.  Slow connections would naturally limit outbound traffic as nodes would fetch inventory from other hosts that advertise that inventory sooner.  That said it might be worth improving the client to take into account connection speed between nodes.

1Mbps of bandwidth is 75MB per 10 minutes.  I would expect someone would want bandwidth for other things so lets assume 30MB available.  This means someone with 1Mbps of bandwidth should be able to handle up to about 10MB blocks.

Given this I wouldn't expect raising the limit to 10MB would have a significant centralizing effect but significantly higher would.  This doesn't account for tor.

Bitcoin does have the potential to grow significantly faster than network and computer speed increases so transaction growth to a point where block size would become prohibitive is a real future possibility.  I expect we have a little time before this becomes an a significant issue but its clearly best to have a solution prepared before its absolutely necessary.

Could we get decent statistics on the bandwidth of internet connections through the world and basically set the block size to ensure something like 95% of the fixed internet connections would be able to run a full node?  Lots of fudge factors in this calculation but its still less arbitrary than 1MB.

As soon as the block limit is hit it will raise transaction fees and there will be a significant need to justify the limit.  The more objective and reasonable the way that limit is set the better.