The meat of this issue was described in #20448 (comment).

Nowhere in the write cmd evaluation/proposal path do we ever filter out no-op commands or commands that decided that they didn't need to write anything during evaluation. Unless I'm missing something, this omission would be pretty catastrophic for this workload. The reason is that a contended workload will naturally result in waves of PushTxnRequests and ResolveIntentRequests. However, in most cases, no more than one of these requests should ever actually perform a write. The rest will usually find a transaction in whatever state it desires and should exit early. An example of this is a PushTxnRequests who finds its transaction in an ABORTED or COMMITTED state. This should be a quick no-op, but I think it will actually result in a consensus write. If each request in these waves actually performs a write, it's more understandable why HeartbeatTxnRequests are being starved in the CommandQueue.

We should change the write cmd evaluation/proposal path to detect no-op results and short circuit them before they are proposed through Raft.