Doesn't the input signal having to propagate through the AND gates cause a propagation delay anyway? With the asynchronous counter the delay was caused by the clock signal - with the synchronous counter wouldn't the delay exist anyway, just with the input instead?
With synchronous counters the delay occurs while the clock is inactive (unchanging, or an inactive edge). When the next active edge arrives at the clock inputs, the data inputs are already stable. Hence all outputs change at the same moment, which is the essence of the system being 'synchronous'.
In typical usage, a synchronous counter will be fed the same clock signal as many other devices. If many devices which similar speed characteristics are fed by the same clock signal, the time between a clock edge and any output changes that result will be relatively similar for all synchronous outputs throughout the system that are controlled by the same clock.
If the signal which feeds a counter isn't fed to anything else, then the timings with which the outputs of a synchronous counter change would likely be more consistent than the correspondings for a ripple counter, but in most cases what matters is not the relation of the counters' bits to each other, but rather the relationship between the counter's outputs and other things which are controlled by the same clock.
Incidentally, note that a typical synchronous counter will often have a "count-enable" input which is expected to be set well in advance of when a clock edge arrives, as well as a carry output which will indicate whether the next clock edge will wrap to zero (which would be true if the count is at maximum value and the enable input is set). One may thus combine multiple short counters into a long one; all of the stages of the counter will know, prior to each clock edge, what they'll do when the edge arrives, thus allowing all of the outputs which are going to switch to do so simultaneously.