Consider a 3 node replica set with a primary, a secondary, and a voting-unelectable node (rollback, initial sync, or recovering). Consider the case where all nodes are replicating from the primary. The primary takes writes at times T1, T2, and T3 with w:majority. The secondary replicates the write at T1, and the voting-unelectable node replicates the writes at T1 and T2. The primary will see that T1 and T2 are both replicated to a majority and it will commit them and acknowledge them to the client.

Now, if the primary crashes, consider what occurs. The secondary is behind the voting-unelectable node, so the voting-unelectable node won't vote for it (and can't because then we'd lose the majority-committed write), but the other node is unelectable. We will thus not be able to elect a primary. If the unelectable node is also inconsistent, this is even worse because there is no way to make it electable.Thus we should not update our progress if we're unelectable.

The node should not vote "aye" either. While voting "aye" will not cause us to lose committed writes (assuming we do not update progress as above), it will cause the unelectable node to vote for nodes that cannot commit writes, since it cannot be part of a majority to help commit writes.