Thanks for your response. I used reference types for Widgets and RenderObjects (primitives output by the Widgets, e.g. Text, Rectangle, etc.) because:
Each Widget represents one UI element that has a unique identity in the application as it is displayed at only one location on the screen. Being able to easily create many detached objects representing the same interactive element didn't seem useful to me.
Both types are organized as tree structures. And implementing them as reference types allows for all updates to Widgets and their outputted RenderObjects to to be resolved inside each Widget. On the next render cycle, the whole tree state will be up to date without any special update logic.
There are edge cases where things need to be hacked together somehow to get a specific look or functionality. One function facilitating this is the ability to hold references to Widgets outside of their direct parents and do anything with them. Normally you define custom Widgets that are composed of multiple pre defined Widgets to create your views. If you want to you can assign a Reference (actual class in the framework) to each Widget which will always point to that Widget after it has been mounted. That way, not only the direct parent, say a layout Widget such as Row or Column can access their children, but also the custom Widget you defined for your view. This gives you the ability to hack something together.