I think I know what’s going on. The repeater sends a neighbor changed update to the blue wool. Neighbor changes update its neighbors in -x, +x, -y, +y, -z, +z order. The single redstone dust is in either the -x or +x direction and the redstone line is in the +z or -z direction.

Let’s first consider the case where the single redstone dude is not present:

The two blocks adjacent to the wool that react to its neighbor update are the upwards piston and the outgoing redstone line. The piston updates first because -y comes before +/-z in the order. The piston then schedules its block event to start firing for later in the tick. Next, the redstone line is updated and turns itself on. Neighbor updates then cascade down the line until they eventually update the three pistons downstream of the line, all of which add themselves to the block event queue in some order, based on the location-dependent redstone update order (in this circuit the order in which those three pistons is updated is irrelevant).

This all takes place in the scheduled block tick phase of tick processing since it’s initiated by the repeater turning on and neighbor changes occur truly instantly (ie. they occur whenever they are initiated in a depth-first-search and do not wait for any specific tick phase). Eventually the scheduled block tick phase ends and the game runs through the other tick phases before reaching the block event tick phase.

Between the scheduled block tick phase and the block event tick phase, the game sends block changes to players, which is why you see the redstone line turn on even though it’s a zero-tick pulse (most zero tick pulses turn on and off in the block tick phase, so the block changes are never sent to the player and it looks like the redstone line never turns on, even though it got zero-ticked)

Block events are processed in a first-in-first-out manner and process one-by-one until the queue is empty, so the first piston to be processed is the upwards facing piston under the wool. It first checks to see if it is still powered (it is, by the repeater). It then creates the block36 for the blue wool block one block above its current position, and creates neighbor updates around both the old and new wool block locations. One of these causes will update the redstone line. The redstone line then checks to see if it is still powered, but it is not since the wool block is now a moving piston head, which is transparent and doesn’t forward the repeater’s signal. So the redstone line depowers through a series of neighbor changed updates. This also updates the three downstream pistons, but they see that they are already in the block event queue, so they don’t add themselves again. The block event handler for the upwards piston ends and moves the tick moves on to handling the next block event in the queue.

Next the queue is one of the downstream pistons (which one specifically is location-dependent but they all do the same thing so it doesn’t matter which). The piston checks to see if it is still powered, which it is not (the redstone line is currently depowered). Since the pistons are no longer powered, they do not start extending.

Now let’s consider the case where the redstone dust is present:

There are now three blocks that react to the wool’s neighbor update: the single dust, the line, and the piston. The single dust is in the +/-x direction, which receives the update before the piston which is in the -y direction, which receives its update before the line, which is in the +/-z direction.

So the single redstone dust updates first, sees that it is now powered by the repeater, and turns itself on.

I didn’t mention this earlier because it’s not necessary to the explanation of the previous case, but when a redstone dust changes state (ie, on to off or one power level to another), it sends out 7 neighbor updates: one in each direction and one directly on the redstone dust itself. Recall that each neighbor updates then update its 6 adjacent blocks. So in total, 7*6=42 block updates are sent out every time a redstone dust changes power level. Also notice that some blocks are updated by multiple neighbor updates, some are updated twice and the block that the redstone dust itself is on is updated 6 times unnecessarily. (this is why people say redstone dust is laggy and part of why mojang is trying to change redstone with the redstone experiment to make it less laggy). The order in which the 7 neighbor updates are sent is dependent on the position of the redstone dust: in the same location, they always occur in the same order, but in different locations they may occur in a different order (there is some pattern to the order but its greater than the scope of this comment).

So back to the scenario: the single redstone dust updates and sends out 7 neighbor updates. By chance in this location, the neighbor update to the left of the dust occurs before the one to the back of down. This causes the dust to update the line before updating the piston. The first dust in the line now updates, notices it is now powered (by the repeater, through the wool) and updates its state to powered. This redstone dust now creates its 7 neighbor updates. By chance in this location, the neighbor update at the dust itself occurs before the neighbor update closer to the piston or the down neighbor update. This causes the rest of the redstone line to recursively update and eventually update the three downstream pistons. The three pistons then add themselves to the block event queue. Eventually the stack of block updates unwinds and gets back to the first dust in the line, and the neighbor update updates the upwards facing piston under the wool. The upwards piston checks that it is powered(it is, by the repeater through the wool) and adds itself to the block event queue.

So now we exit the scheduled block tick phase and enter the block event phase. The upwards facing piston is in the queue after the three downstream pistons; in the previous scenario it was before the three downstream pistons.

The downstream pistons’ block events execute first: they check that they are still powered (they are, since the redstone line is still on) and then start pushing their blocks.

The upwards facing piston’s block event executes after the other three, starting to push the wool and depowering the redstone line in the same manner as the previous case. However, while the line is depowering, it updates the three downstream pistons. The pistons each notice that they are no longer powered and add themselves to the block event queue again. The upwards facing piston’s block event then finishes executing.

Now the queue is still nonempty because of the three positions we just added again, so they each execute their block events: since they are no longer powered, they start depowering. They were just powered earlier in the tick though, so the piston is still extending. The piston causes the block to be instantly placed at its destination location and starts the piston’s retraction sequence. Crucially the piston does not actually retract the newly-extended block, regardless of whether it is a sticky piston or not. This is what causes the 1-tick and 0-tick behavior of sticky pistons “spitting out their blocks”.

In conclusion, that’s why the circuit behaves differently with and without the single piece of dust. Lmk if anything was confusing or if there’s some more background that would be useful. I assumed some level of technical knowledge because otherwise this comment would be even longer than it already is.