NOTE: fixing this bug will break 4 tick observer clocks (as shown in the attached screenshot "observer_clock.png". Extending the piston will initiate a 4 tick observer clock).
Considering that the behaviour that relies on this bug is ubiquitous and the behaviour that breaks due to this bug is quite obscure, this bug should either not be fixed or fixed in such a way that 4 tick observer clocks are not affected. 

Observers react to updates if they already have a scheduled tick at the current world time but haven't yet been ticked.

When an unpowered observer is updated, it schedules a tick 2 ticks in the future. In the meantime it should not react to any updates. However, if the observer is updated before it is ticked but in the same tick it is scheduled to be ticked, it schedules another tick anyway.

This behaviour can easily be recreated using the setup shown in the attached screenshot ("observer_bug_setup.png").

If the bottom observer is updated by changing the delay on the repeater, it will power, first updating the top observer to power and then itself to depower. The fact that the bottom observer will depower after the top observer powers is important, because it will cause the piston to extend. This is the expected behaviour.

However, if instead a short pulse is sent through the repeater (which has to be on the lowest delay setting!) the circuit behaves differently. The repeater depowers in the same tick the bottom observer powers, but before it is ticked. Instead of ignoring the update, the bottom observer schedules another tick. This causes it to depower before the top observer powers, causing the piston not to extend.

Code analysis

The way the observer makes sure it does not schedule a tick if it already has a scheduled tick is by calling the hasScheduledTick(BlockPos, Object) method in the net.minecraft.world.level.ServerTickList class. This method returns false if the given position has a scheduled tick at the current world time.

Looking at other redstone components, the repeater and redstone torch for example do not call the hasScheduledTick(BlockPos, Object) method but rather the willTickThisTick(BlockPos, Object) method, and are not affected by this bug.