Hi Nicholas
This is not well implemented, and it has been on our to-do list for quite some time to overhaul how script and style dependencies are added, and how they can be managed by clients who want more control over what is added where.
There is a basic issue relating to how the page is constructed by WordPress. A View or a Form, for example, could be added to a footer widget, but by the time we arrive there it is too late to enqueue a stylesheet that should be included in the page head, for example. So the developers took something of a kitchen-sink approach originally, namely to add scripts and stylesheets on pages where they might be needed, which means adding them in places they are not.
And in a handful of cases the dependencies are not entirely logical.
So, some preliminary work has been done on rethinking and re-implementing this, given the increasing emphasis on performance. It is not actively part of the current Views dev cycle—there were a handful of issues considered more urgent—but I will be pushing strongly for us to finally update this in the next Views dev cycle, which should start within a couple of months.
In the meantime there is not much I can tell you. We don't have documented what is added where and needed when. If you intend to manually dequeue unnecessary assets, it's a trial and error process, I would only know by going through the same steps myself, and each site may have different needs.
What I would say is that if you only have Toolset content (e.g. Views and Forms) on certain pages or archives, you could check for which page is being loaded first and effectively have a whitelist, where you don't dequeue Toolset assets, and go ahead and dequeue them on other pages. So the non-Toolset pages will see a clear benefit, whereas the benefit on Toolset pages may be marginal in any case (because some of the assets, if not all, would be required).
You could then revisit this later in the year when we should have tackled this.
