My main concern with “putting transaction ordering in consensus” approaches is that it puts a lot of pressure on a mechanism that could easily have a lot of instabilities and a lot of paths by which the equilibrium could collapse. One simple sketch of such a mechanism is: attesters refuse to vote for a block if that block fails to include a transaction (i) which the attester has seen for at least a full slot and (ii) whose priority fee is more than 1.1 times the lowest priority fee included in the block.
The main question is: what’s the incentive to actually enforce this rule? If an attester sees that a given block fails to include a transaction that it should have included, but then it sees other attesters voting for that block, it’s in the attester’s interest to also vote for the block, to get the attestation reward. These “follow the crowd” incentives could lead to block inclusion rules becoming more and more slack over time, until no one checks at all. It may even be possible for attackers to submit txs that satisfy the conditions for some attesters and not others, thereby splitting votes 50/50. Having attesters only concern themselves with blocks, and not transactions, avoids all of these issues, because there are far fewer objects that could manipulate the fork choice in this way, and it’s more clearly expensive to create 50/50 splits.