This undead thread is fundamentally flawed in any and all assumptions that are being made as a basis of argument.
Adding transactions to the block you're working on will slow down your generation rate. What prevents the majority of generating nodes from ignoring broadcasted transactions and making the network unreliable?
Theymos made an incorrect assumption, hash rate is in no way affected by the inclusion or non-inclusion of transactions, there is no advantage to not including transactions. There may have been a very small bit of CPU used in the CPU solo mining days when creating a new merkle tree when a new transaction was received, but these days where multiple pools have over 4TH, the number of included transactions in no way impacts the hashing that miners are doing - they don't even know how many transactions are in the block data that is being hashed.
Secondly, even if 50% of the blocks included no transactions, Bitcoin would keep on working. There was already a "mystery miner" that was using a botnet that didn't include transactions, and his 10% of the hashrate was merely a curiosity.
If a bad actor has more than 50% of the hashrate required to deny transaction inclusion on more than half the blocks mined, there is a much bigger problem, as they already have enough hashrate to do a 51% attack and can cause more problems by rewriting block history, double spending and erasing blocks. Bitcoin relies on a majority of mining being good, there is little defense against a majority hashrate attack.
Finally there is no motivation for this. If a pool operator was doing something against the interests of Bitcoin, it would be known and miners would leave. Not including transactions would be passing up considerable earnings.