Thank you, this is what I figured overall. However, I have one nagging question:

Bandwidth, verification load, storage space required are all affected by block size, but not the "mining process" per se. A miner mining in a pool wouldn't notice any kind of a difference, wether he mines on a 1 KB or a 1 GB block.

This isn't strictly true though it may be true in the grand scheme of things. The time it takes to run the hash once is impacted by the length of the data being fed in (i.e. the block of transactions). It's my understanding that sha256 is O(n) time wise but by construction the number of bytes to be hashed must impact performance.

Wouldn't this imply a tradeoff between the length of the block you are attempting to mine and your personal hash rate, thus disincentivizing arbitrarily large blocks but incentivizing blocks that maximize the tradeoff between fees received and P(success)? This assumes that block size does impact hash performance, which I'm having a hard time of verifying. It could be O(l + c) where c is the time needed for the rounds, l is the length of the block in bytes, and l << c.

This is my niggle with variable block sizes... I think that equilibrium, assuming O(n), would rest at the min size regardless because it will maximize the expected value of the mining effort for a given block.

I've been trying for a while to find a serious consideration of this question.