You hit the nail on the head with your general assessment here, but I'd say that you need to expand your analysis to a finer grain than application specific. In a given application/service/whatever there is some data that is best for polling and some best for pushing. You're going to have to make that call on a case by case basis. Best here being completely subjective because best could be long term code maintenance or performance. From an architectural standpoint in enterprise development my recommendation is to use push based systems at the surface and behind the scenes implement polling that feeds into it via adapters if polling makes the most sense for individual messages/data/traffic. For push based systems you have to determine what underlying transport/technology is best suited too. There's Azure Service Bus, Google Pub/Sub, ZeroMQ, Tibco, etc. Each is going to have it's environment. Tibco is popular in financial worlds because it's got a low latency UDP option. Azure Service Bus is super easy to implement and is durable/reliable messaging. Google Pub/Sub has support for huge volume able to handle 1 mil + messages per second. Global Service Bus Architecture in C#[^] Unified Message Bus Framework - Part 1[^]

Yes, you're correct. For some reason I was thinking the underlying source still need to be explicitly hooked, but it does not.

Yes and no. You shouldn't be using a callback in this case. The callback is circumventing the whole point of the binding. Taking my advice would fix it the appropriate way.

The reason why it's not working is the MonthViewDayColumnHeader class doesn't support INotifyPropertyChanged. It's being initialized, then updated with Monday after. If you take the existing and default it to 'Sunday' you should be able to see the default value. On that note, I know it's an example but you should probably start off with MVVM in your learning process. Have the underlying layers implement the INotifyPropertyChanged and set the context to an appropriate view model.