Speaking as a programmer, it's VERY easy to screw up the transaction fee. If you're not using a known bitcoin client and are making your own, it's quite easy to accidentally leave out an output or calculate things wrong. The blockchain won't accept your transaction if you're spending more than the inputs, but will happily accept transactions if you're spending much less than the inputs.

All the errors basically end up going the same way (that is, in favor of the miners), so I'd imagine it's people like me who are testing something or trying to be too clever. This, by the way, is why you should be using testnet for software that's not ready.

It would seem using a large Tx fee is an attack vector in that miners will all realign to try and solve the block at height n, which is quite different to the normal situation where it's usually two chains competing for length. The outcome requires 100% "rational actors" trying to mine the block height n and the ability of the nodes to detect the errantly/anomalously high fee.

A description from the blog of the Freeze Attack, postulating a ฿50 Tx fee:

The freeze problem occurs if someone publishes a transaction with fees much higher than the block subsidy. I don’t remember who described the attack first. Suppose that, by mistake, a transaction is published with 50 BTC in fees. The transaction is included in a block at height n. If everyone acts rationally in his own interest, then the best choice for the remaining miners is to try to mine a competing block at the same height n including the high-fee transaction, to collect the fee for themselves. All the miners having solved the block at height n, now move on mining at height (n+1). But they won’t choose each other branches until one branch is sufficiently longer so that it is better to switch to it and abandon their own branch rather than try to keep the block with the high fee. This case is different from the real block competition case we see periodically on the blockchain, where the miners are generally split between two branches. Here there are multiple branches competing. If there are 10 “top” miners each having 10% of the network hashing power, then 10 different branches will compete. The analysis for this case is similar to the Gambler’s Ruin problem analysis present in the Satoshi paper, but with a fixed constant monetary incentive not to switch. Since the incentive to switch grows exponentially with the branch length difference, any initial constant is diluted. In the special and rare case that all the miners have exactly the same hashing power, then the network diverges, and this is equivalent as having two miners having exactly 50% of the hashing power each. So in principle the freeze on transaction problem is just a temporary disruption in the network, but not a fatal halt. Nevertheless, since during the freeze period each miner is mining on his own branch, it also means that moving forward with blocks is a lot slower. Assuming 10 miners having 10% of the total hashing power each (+/- 3%), the network becomes 10 times slower. I simulated it with a 50 BTC tx freeze fee, and 10 miners, and it takes approximately 6 blocks to converge, so the freeze time is approximately 60 times the block interval, or 10 hours. If the distribution is approximately 25% of the hashing power for each top miner, the freeze time is 4 hours.