Hi Carla. I can think about two things. The first one, is the one Levente said, performance.
If you analyze the bycode of this method, you will see that it is extremely fast because:

1) #== has an special associated bytecode, that is, them VM maps such bytecode to an specific primitive and it is directly executed. It means that the method #== is really never sent.
2) ifTrue:ifFalse: is also optimized (inlined) by the compiler. Again, it method is never executed and instead the compiler replace a message send bytecode with jump ones.

Another possible reason (it may not be the case, but in another places it is), is to prevent VM interruption for check other processes. In summary, the VM checks whether it should execute another process of the queue after a method execution. As you know, some parts of the scheduling process is done at the image side. And from there we lack a way to say to the VM, "please execute this method without checking others processes". Hence, in a few yet very specific places of PRocess, Scheduler, Semaphore, etc, #== is used as a mean of executing something WITHOUT being interrupted. I can imagine that it may happen the same with #~~. So if you implement such method with a #not, you will indeed send a message, proving a possibilty to be interrupted.

Another reasons, similar to the previous one, is that sometimes #== is also used as a way to avoid executing method. So..there are some methods (I don't remember if #allInstancesDo: or #allObjectsDo:) will loop forever because the loop condition would be creating objects (remember that method execution creates objects such as MethodContext).
So...again, I think it may happen the same with #~~.

That being said, I agree that the method deserve a GOOD comment explaining the reasons of such optimization.

Cheers