Let's suppose you start the program and click into the upper-left Entry; if you hit the tab key, moving focus out of that Entry - without typing any characters in it, focus moves to the lower-left Entry, and the validation for the upper-left Entry gets called only once.
Hit tab again (without typing anything into the lower-left Entry): focus moves back to the upper-left, and the lower-left validation gets called once. Using just the tab key, you bounce back and forth between the two left-hand Entries, and with each focus change, the validation for the Entry you're leaving gets called just once. (UPDATE: What golux said above about the right-hand Entries being disabled on start-up explains why focus only bounces between the two left-hand Entries.)
Now, when you type something into a left-hand Entry before hitting tab, the tab moves focus to the other left-hand Entry, and validation runs once on the Entry where you just typed something in. Because there's content, your validation script for this widget (which doesn't have focus now) moves the focus to its associated right-hand widget.This step causes a second "focusout" event, but this time it's triggered on the other left-hand widget (the one that actually had focus when the validation function started). (UPDATE: Of course, once there is content in a left-hand Entry, its right-hand Entry becomes active, and this changes how focus moves when using the tab character.)
In effect, the way the OP code is set up, whenever focus leaves a non-empty left-hand widget, validation gets run on both left-hand widgets: the first is triggered by the "focusout" caused at the keyboard for one of them (shifting focus to the other), and then the validation forces a "focusout" on the other.
Is there some compelling reason why two pairs of Entries need to be used in combination this way? If you handled just one password_entry + password_confirmation pair, you wouldn't have this problem.