There are multiple reasons for large lists of dirty objects.
We have a production system which can plan future productions. With this a large list of objects (single production jobs) are created which then will be deleted after production (which can be immidiatly, or the production will be done in a few days).
The production jobs will be displayed in another process. The executalbe with the production window can run on the same system. Or on a distinct one. So if anyone deletes a complete production tree in a planning window it needs to be also deleted in the production window.
The refresh of the Gridview displaying the items is minimized (only rows which are visible get refreshed) - but if objects are added or deleted the grid will also need to have knowledge about what is deleted.
We are not using one objectscope but multiple ones. The most "windows" can be also started as standalone component.One central component informs all objectscopes and grids about changes. (With only one scope we had large problems as the background planning job and windows can do commits at the same time. If we encapsulated transactions the background and foreground jobs were sometimes mostly waiting for a lock, and we have seen situations were a grid then dies).
Its not only about processes on the same computer, it can also be different databases on different sites. ). Think about central planning at one site, and production on different other sites (plannign is maybe a bad example as it can also be done at same site, but as objects belong together and statistic objects will also be produced it is safer to have complete object trees instead of having objects with missing informations on one system and corresponding informations on another one).