If it were always better, I wouldn’t have gone to the trouble of introducing bindings
Lets take health as an example, you expose a public Health property on your Character. I shoot him, and call Damage, which internally adjusts the health and then fires an event which you hook and then update the UI. Cool. Later - you introduce health pickups, and instead of damage, it heals you. Now you have to have have an OnHeal, or maybe you generalize it as OnHealthChanged. That’s not so bad for one property, but keep in mind, you must always remember in your game code to never directly modify Health without calling OnHealthChanged, or your UI will be out of date.
Imagine doing that on every value you ever want to display in the UI that could conceivably change due to gameplay. Player Name, Weapon stats in an RPG (maybe you want to show the value with buffs included), the list can get pretty long.
With Binding you avoid all those problems, whatever the value, that’s what the UI shows. In the future we can improve the performance of bindings, (possibly with invalidation options, time based invalidation, or maybe with events). Which is why it’s better than doing it in Tick, and if all you are planning to bind is a handful of properties, it’s not worth worrying about the performance, so better to err on the side of bindings instead of manual updating.
In the end, we provide both so that you can pick which ever you’re more comfortable with, or will fit your use-case better.