Theoretically it makes sense, because (sounds bad, but that’s the technical terms) the slave isn’t the one to send commands to other slaves and it’s master. As slaves don’t know who the master is, just know they have to listen to incoming commands, messages from „wrong“ sources can lead to race conditions, weird behaviour in some situations. Maybe it caused those for some users and devs used the work on synchronisation to fix that.
On most of the devices I own, setting the device to slaves turns of controll messages too.
Some more info on what can happen:
Midi sync is done by the master sending midi clock messages regularly. The slaves receive them. Measure the time in between them and calculate the tempo they have to run on. That’s the reason why tempochanges can mess up tight beats over midi.
The Start-command just tells everyone to run. So a Device that receives that start command takes the tempo it knows and starts running, waiting for clock pages to come to sync to it. Some devices just update their tempo (and run out of sync that way) others bind their sequencing to that and „reset“ internally if needed. Either way, latency is an issue here. If the slaves starts running before the master does it, or dependent on tempo even if at the same time, both because the message
Comes from a wrong source, it can happen that clock steps are skipped, tempo gets messed up a lot etc. while working on my sequencer. It makes a big difference if you send the start directly before or directly after the clock message.
To have all that save is to just have the master do all that. And the only way you can attempt that is to forbid slaves to mess with that.
