FWIW, the technique of one software component disabling another is not a ‘best practice’. By “disabling” I don’t mean simply influencing the other’s behavior but outright shutting it down.
It’s an expedient technique, that I have seen suggested more than a few times, but it isn’t optimal. Aside from the questionable design philosophy, one loses the ability to definitively and reliably disable an automation.
For example, if you had a good reason to turn off an automation (due to a malfunction that you intend to resolve at a later time) you can’t be certain it will stay off. You might have one or more other automations that will turn it back on. (As luck would have it, it will probably be turned on at the worst possible moment.)
Optimally, each automation has access to all inputs needed to properly guide its behavior. Short of that, a global “flag” can be used (like an input_boolean) to signal one automation’s intentions to others (and thereby influence their behavior, not disable them outright).
Analogy:
Imagine a team sport. Each player knows their role. Their individual actions are influenced by the actions of their team mates.
You pull a player out if they are injured, fatigued, or under-performing. You don’t pull a player out to temporarily stop them from performing their role. You train them to be better at it. That might even require changing the behavior of other team mates so everyone works together more effectively.