My problem with this justification is that these problems have been solved for a long time with simple message passing. In Win32, you just post a message to a window handle from the background thread to notify the UI of status updates, etc. Yes, you do need to worry about shared state/locks if that "message" includes more than a simple integer. But, these are also solved problems and rarely require more exotic lock-less queues, stacks, etc. for the majority of applications that use these types of architectures for UI background processing because the performance implications are inconsequential. Using a shared stack that uses a simple critical section will work fine for managing the messages, especially since Windows now has critical sections that can use spin locks to help minimize context switches.
It's a solved problem in a sense that yes, you can do it that way. But it's also more conceptually complicated, and much easier to get it wrong, which is evident by the fact that so many desktop apps on Windows still lock up occasionally. Not so with UWP apps.
