Earlier quoted context omitted.
And - as the article describes - such a blocking mode would immediately expose to WhatsApp which users had not enabled it, and who would therefore be safe(er) to MITM (because they probably don't verify key changes in any meaningful way).
why? The UI on the receiver end could show the warning, not the message, and in the dialog to the Whatsapp systems behave normally. In that way the user would be notified of rekeying, the MITM attacker wouldn't be notified that the user is security consious.
t1: Server sends message (1) to Client B
t2: Client B fails to decode message (1) due to an outdated key. Sends failure notification to Server
t3: Server sends rekey notification to Client A
t4: (usually 1 second) Client A sends rekeyed message (1') to Server for Client B
For t4, if the Server notices the response from Client A came faster than a user could ever have seen and responded to a notification, it now knows Client A is more susceptible to a MitM attack. If, on the other hand, Client A takes an appreciable amount of time to send the rekeyed message (say, 1 second or more) then we know that either there was a network latency, or the user had to respond to a rekey notification before the message was resent. We should be more careful about launching a MitM attack on this class of user.
So, without changing the actual _actions_ that the Server sees, but just the pattern of the timing of those actions, we're still leaking important information.
Note: all numbers completely made up.