Which is better and why: broadcasting a signal vs polling a property for state changes?

Neither approach is universally better; the right choice depends on how frequently the state actually changes and how quickly a subscriber genuinely needs to know about it, since signals and polling make opposite trade-offs between efficiency and simplicity.

Broadcasting a signal, such as PropertiesChanged, is efficient because it only generates traffic when something actually happens, and subscribers find out immediately rather than after some polling delay. Its downside is added complexity: the subscriber has to correctly register a match rule, handle the async, event-driven nature of receiving it, and gracefully deal with a signal being missed, for example if the subscriber wasn't connected yet when it fired, requiring an explicit Get or GetAll call on startup to establish the current state.

Polling a property with repeated Get calls is simpler to reason about and self-correcting, since each poll reflects the true current state regardless of what was missed before, but it wastes bus traffic and CPU on every poll where nothing changed, and it introduces a detection delay bounded by the polling interval.

In practice, the common and most robust pattern combines both: subscribe to the relevant signal for low-latency updates, but also call Get or GetAll once at startup to establish a correct initial state, rather than relying on either mechanism exclusively.