in my scenario the view model nodes were initialized with IsExpanded = true and the IsExpanded binding was used on the TreeListView.
Your TreeListView seems to be implemented in a way where the expanded states of the view items are realized when the view item rows come into view. It is clearly visible that the rows are first rendered collapsed an then expanded. I can remember, that the expanded state is applied delayed through BeginInvoke or something (I have opened an issue long time ago, and this was by design).
Now I thought that this on the fly expansion causes the performance issue while scrolling. It was really not ussable with 240.000 nodes at two or three levels. So I was near giving up when I found the "AutoExpandItems" property. I have set it to true, and the scrolling problem was gone completely. I think because the view expansion state and the view model expansion state were in sync. The delayed expansion was gone.
But then I realized that the initialization and cleanup times have increased dramatically. Looking into your sources it seems, that your code collapses all nodes from the deepest level to the heighest when the view model collections are cleared. Each collapse seems to trigger UI updates. This consumes too much time which is dependent on the number of expanded nodes. I think that "AutoExpandItems" only helps to uncover the underlying problem. The problem would (maybe) also be there, if I would expand the items manually one by one (if I had the time to).
Btw: The deferred scrolling is not accepted by our PMs. It is a way to scroll which is not known by a default windows user. I must also admit that I have never seen a program on the market which uses deferred scrolling.