The reason is that Treeview is where a lot of "rubber meets the road". It scrolls. It has icons that likely change state. It has active widgets. It may have a LOT of widgets and be a good test of performance. It has text and all of the idiocy that entails. It may or may not have selection. It has a connection to backing data.
So, you get a nice microcosm of how you should plumb together the components of the UI toolkit if you look at the Treeview implementation.
However, I would like to provide the contrarian position, as well. I find that far too many people use Treeview as a substitute for actual design. I often find that the TreeView really should be something else--a config file, a table interface (table interfaces are really underused in GUI design given how many of your users are wedded to Excel for business things), etc. Everything doesn't need to be pointy-clicky and often throwing things out improves your GUI.
Treeviews tend to be the laziest of options--and, as we all know, programmers are very lazy.
Not the parent, but a tree view is convenient for an app that has a lot of settings. For instance you can take a dictionary of settings and create a tree view with the same structure. If a setting gets added later, you don't need to rearrange the GUI, it rearranges itself.
I've seen this kind of GUI in programs that manage complicated hardware such as scientific instrumentation.
