We do know why, but it can be lengthy to explain. I’ll try and keep it as short as possible…
Locking a DAC to a Master Clock which does not have to contend with all of the sources of phase noise the DAC does (CD mech vibrations if present, power supplies running different circuitry causing changes in the power rails fed to the clock, the EM leakage from said circuits and additional processing for other functions like D/A conversion, heat generated by the product changing the frequency of the oscillator) means the DAC then has a much more stable reference to adjust its own clock to.
Why is this preferable to simply locking to the sync pulses in, for example, the SPDIF or AES signal coming from a CD transport to the DAC? Well, aside from the fact that the CD transport’s clock(s) have to deal with very similar sources of phase noise to the DAC which would put jitter into the signal, an effect called intersymbol interference comes into play.
When a digital signal is passed through a cable, the cable will act as a filter to a degree. A poorly designed cable, which is unfit for use with the interface it is designed for – like AES3 – could potentially filter out high frequencies from the signal before it reaches the DAC from the source device. This causes an interaction between any two consecutive data bits within the signal, called intersymbol interference. Depending on the relationship between one bit and the following bit, the transition between the two can be temporally smeared – the clean vertical line of the digital square wave becomes a sloped line, meaning the exact moment a 0 changes to a 1 or vice versa can be blurred. In short, jitter can be introduced purely from the interactions within the data itself.
If the timing data from the audio signal is being used to lock the DAC’s clock to, this intersymbol interference will have a negative impact on sound quality, as it can introduce jitter to the DAC’s clock. However, if the audio system is making use of a Master Clock, and the timing information embedded in the aforementioned AES3 signal is no longer being used, the effects of intersymbol interference are negated.
While the same sort of filtering can of course occur on a clock cable, as the signal is perfectly regular the filtering causes no timing change from one bit to another – no jitter from intersymbol interference.
Now, all of this is subject to how the PLL in the DAC is designed (the PLL is the circuit which locks the DAC’s clock to the same rate as an incoming signal) – should this actually have an impact in a well-designed DAC? Well, as with any engineering there is no such thing as a free lunch. If you design your product to reject interface jitter which is coming from outside the DAC (let’s say a jittery signal from a CD transport), you better make sure your DAC’s clock oscillators are very good, because your system will be more susceptible to intrinsic jitter (such as phase noise) as a result. If you are using a low phase noise oscillator such as a VCXO, this is doable – this is the approach we take. If you are using a VCO or to a lesser extent an OCXO based clock, you may have to bias the system’s PLL somewhat more towards accepting interface jitter to reject some of the intrinsic jitter from the oscillator. This may be necessary to get the best from that product. It’s a trade-off, and how the product designers work out which route to take depends on a huge number of things, not least product price point and use case.