Let's do the math, conservatively. Suppose there's an event and the intent is to broadcast at 60 fps (which is on the high side) and that you want to be able to switch between cameras or even composite multiple camera feeds together without skipping frames or interpolating between frames. That gives a budget of 16.7ms per frame. (Hey, this is a lot like making a video game! Fortunately input latency is not such a big deal here because the viewers aren't playing.)

Suppose you give a budget of 4ms to composite the frame. Now you have 12.7ms from the end of the previous frame in which to collect the current frame from each camera and do whatever fancy processing you want to do (drawing first down lines, adding ads, etc). Of course, you can always cheat a bit by pipelining frames, but this adds latency, and maybe you would prefer to avoid that. Let's say you don't want to pipeline and you budget 8.7ms for all this fancy work, which gives you a 4ms window in which to receive all your incoming frames, which need to be in exact lockstep from all cameras. (This is very, very conservative, since, again, this is not a videogame and it's probably fine to buffer all inputs for a few tens or even hundreds of ms. I'm ignoring the time to transfer each frame -- I'm assuming we're counting from the end of the frame transfer time. If it takes a full frame to transfer a frame, then you cannot possibly avoid one frame of transfer latency anyway.)

So you need all those fancy cameras to stay in sync to plus or minus 4ms. That's a piece of cake with basically any modern technology, where "modern" means, I don't know, the last 30 years? NTP can do this. PTP can do this even with a fully software implementation and no assistance from the switches whatsoever. A cellphone can do this. A fancy GPSDO can do orders of magnitude better than this. A decent RTC will take a whole 200 seconds to drift by a problematic amount. The only actual fancy tech needed is the ability for the host controller on each camera to discipline the camera's frame clock, which I imagine any camera worth its salt can do.

I don't see why a $30k clock is useful here, or why very fancy protocols are needed. I do see why there's a need to get everyone to agree on a protocol, though.

I did once watch an event where I was genuinely impressed by the synchronization, though: a parade at a theme park. There were hundreds or thousands of fixed speakers and hundreds of mobile speakers in the parade, and all of them stayed perfectly synchronized, playing parts of the same music, to within the precision of my ears. I'm guessing the design goal was better than 1ms synchronization error, over at least half an hour, across acres of space, in a potentially adverse RF environment (at least the ISM bands would have been horribly polluted by everyone's phones). And possibly the mobile speakers would even have needed to compensate for their own locations due to the speed of sound being kind of low and the actual parade speed possibly being a bit unpredictable.

If I were designing that, I might have used GPSDOs on each mobile element or possibly some kind of wireless clock distribution -- a 20ppm clock is not even close to good enough.

But event broadcasting doesn't have these problems per se because, anywhere there's a camera, there's already a reliably, high-bandwidth data link of some sort so the camera feed can get to where it's going in real time.

Surprisingly, the timing requirements for digital seem to be slightly lower than it was for analog, at least if I heard the engineer correctly on site. It was something like 1.5 microseconds in the old days, but can be like 10 microseconds now. I could be wrong there.

No, you are right. And it is because digital has a much wider 'lock' range than analog. Analog only works 'in the moment' whereas digital can take the history of the signal so far into account and so not lose lock. If it gets too extreme it will still happen though so cumulative problems will still show up only much later.