There is conceptually no difference between the goals of CSD + SIFT versus global tractography; I fully agree with that.
My argument was actually not about those, but about being able to incorporate ACT (or any other mechanism for such anatomical constraints) in the pipeline; and furthermore in the correct spot/order in the pipeline. The problem, with respect to this particular scenario, is that the current implementation of global tractography in MRtrix can not enforce anatomical constraints, including (but not limited to) enforcing that tracks connect grey matter with their endpoints. One could enforce this, for example, after global tractography, but then the particular fit to the data is broken. This is essentially what happens when constructing a connectome of, e.g., the global tractography output.
The other option is to do CSD + anatomically constrained tractography (ACT) + SIFT. The difference is that the tracks are, in a way, “a priori anatomically constrained” at the stage where SIFT takes care of the fit to the data. So you end up with a tractogram that fits the data, but is at the same time also anatomically constrained. What @chunhungyeh’s abstracts show (as well as @rsmith’s earlier works), is that this has a very significant impact on the resulting connectome (and derived metrics thereof). The abstracts also explore (even) further challenges, such as the track assignment mechanism; but these are unrelated to my explanation here.
Independently from this, I don’t know of works that would have directly compared the performance of (MSMT-)CSD + SIFT to global tractography in terms of fitting the data. If ACT is incorporated in the former, it’s not unlikely that it may perform slightly less well in fitting the data; in this context, you could see ACT as a further regularisation (well, actually a hard constraint, if you will) of the problem; but it is there for a purpose of course. But as I reasoned, this all depends on the application.
So, what I’m essentially arguing, is that a mechanism for anatomical constraints is essential if the application is to be “quantitative connectomics”.
I hope this explanation makes sense. (if not, @rsmith will have to give it another go )