The decision to not include transactions was made after support for transactions was already in place. It is a political decision, not a technical necessity.
For the lack of logic, just think about how your own mining client works. Most of you readers (yes, not all, but most), are mining at a traditional pool. You consume very little bandwidth, you dont need to store the blockchain and you dont need to know or verify any TXs. Yet your mining effort works towards blocks with transactions included.
You work successfully under exactly the same conditions, as (some of) you claim would force a botnet to exclude transactions. (Some of) you say, that downloading the blockchain would make botnet victims suspicious, yet you do not need to download it yourself! (Some of) you say, the steady influx of transactions would need lots of extra CPU processing and extra network bandwidth, yet you do not need to do that yourself! (Some of) you even say that a full bitcoind must be in place, yet you do not need it on your own miners!
Your own mining client shows how the technical "problems" can be solved, and source code is available for everyhing (both mining client and pool service).
The assumption of the technical benefit is just plain false. The only thing that supports the idea of a botnet, is the ever repeating posts here on bitcointalk. Those who jump to early conclusions and keep reinstating this false idea, are the ones who do damage to bitcoin.
I wonder if you stand up as quick to apologize as you do to condemn.
If what you're saying is true, and I'm not knowledgeable enough about the various BTC miner software versions to know, then gmaxwell's proposal would not work at all, and would be a huge pain since it requires a protocol change.
It seems to me that if you're right, then it's most likely a bug, since it's inconceivable that anyone would purposefully omit tx unless as T&D stated it was to maybe to reduce server loads on an already stretched system. Unless "mystery" steps forward, assuming it's even one person, we couldn't know their intentions.
Also, if this is the case, then the method proposed by Gavin/Revalin would be necessary. If a block has far fewer tx than the average, then it gets delayed, and if it has only 1 or none it may be excluded altogether.
There are several reasons why the "I'm entitled to charge whatever I want" argument has no weight.
1: I can charge $1million USD for a single grain of sand on ebay. Nobody will buy it (I would hope), but I still have to pay for posting it at auction. In BTC if you do the same thing you still get paid, at the expense of everyone using the system.
2: Gavin/Revalin's system still gives miners a good deal of room in choosing what they want to charge. As long as the threshold for delay isn't too restrictive, and the miner is charging a reasonable enough fee that they actually get
some business, they shouldn't be excluded or delayed. Unless your business model is crap, there's no penalty. Also, since it's not actually part of the protocol, there's no obligation of any party to delay or reject a block, nor any obligation to accept any block, and it could potentially be adjustable by the user. I think, however, that the sentiment of most miners is that they also are not interested in supporting cheapskates.
3: The blockchain is 2 fucking gigabytes, and climbing at an absurd rate. If I have to download a 2GB blockchain, and 15% (or more) of all the blocks are empty or nearly empty, then why have I wasted my time downloading 300MB+ of that? The only purpose of the blockchain is to be able to securely verify transactions that have occurred, and empty or nearly empty blocks add filesize without contributing to the purpose of the data. At the rate things are going it's already going to take further development just to figure out how to keep the size reasonable, and the last thing we need is a bunch of retards being paid in inflation to spam it up faster.
Finally, if it
is just a bug in one of the clients rather than someone trying to take shortcuts, then implementing a screening system would make it obvious to the users of that client that something is wrong. In that case it probably wouldn't take long for it to be fixed. If nothing is done, then we have no way of knowing.