@Mulled7768 Than you for taking the time to dive deeper into the sources, and to elevate our discussion of Argon2id. Unfortunately, I currently do not have the time to read the sources you cited and form my own opinion of what conclusions they support (although it would have helped if you had provided direct links).
I believe that the ultimate conclusion may be that we are both right under different scenarios.
That being said, for now, none of the passages that you quoted in your first comment are convincing to me — I can interpret each of them as being consistent with the arguments I have been making earlier in the thread.
On the other hand, in my comment from last year where I first describe my take on analyzing the Argon2id costs, I concede first of all that “my understanding of this is not 100%” (which is still true), and importantly provide the following disclaimer (which also applies to everything I have said so far in the present thread):
Based on the reference to “memory cycles” in your first comment, and the GitHub benchmarking data in your follow-up comment, I believe that the scenarios in which your point of view (that increasing parallelism results in an unchanged or even improved cracking resistance) will hold, and my assumption that parallelism reduces cracking resistance will be invalid, are precisely those conditions in which the hash calculation speed is limited by bus transfer speeds.
Hopefully you agree that there exist situations in which bus speeds are not rate-limiting, as demonstrated by the fact that unlock time on a mobile app can be reduced by increasing parallelism. The challenge is to determine under what conditions does the bus bandwidth become a greater constraint than the memory availability.