My two cents…
The situation I think you’re working with is you have a GameState which has a dozen or so variables you want to display to the player via the ScoreBoard. You’re not wrong, this is a very common situation but there are multiple ways to solve it as different projects have different needs. That said, you essentially have 2 models (or a combination thereof) to work with.
Model A
Your GameState has a bunch of RepNotify’s, from which you call out to the ScoreBoard to update the appropriate piece. This of course means you will need a reference to the ScoreBoard…not a bad thing.
Model A (version 2)
Your GameState has a bunch of RepNotify’s, from which you create call an event dispatcher for each. Yes you’ll have more functions but now anything can bind to the event and get updates, not just the ScoreBoard (if that’s something your project needs)
Model B
Your ScoreBoard periodically updates (via an event timer) itself with the current state of the GameState…say every quarter of a second. The ScoreBoard could have a reference to the GameState (or gen one on the fly)…again, not a bad thing…and update its display.
The obvious benefit of A over B is that you’re only making changes when changes occur vs B which is running every quarter second to update things which might not have changed at all. Generally speaking the guidance for this situation is RepNotify.
IMHO EventDispatchers, while good design, might be a bit overkill for this situation. That said, there are benefits, as @BRGDemianLopez pointed out, if you had multiple consumers (so multiple places that needed to reflect the change), you would only have to make one call and have all pieces attach to the event. The example setup you showed is not what I think @BRGDemianLopez meant. Essentially your GameState should have an event which you then call…let’s say QuarterUpdated. Your scoreboard would then bind to that…maybe on begin play. Then you would just call the event, no need to reference the ScoreBoard.