Here it's natural but inflammatory when participants view discussion as a contest with advocates, or consider how to convince the decider in their favor. That approach can make silence or non-responsiveness appear to be intransigence, or can end up targeting LSG members and influencers.
But because it's natural, I would hope the review managers can do more to re-orient reviewers; currently, the notion in the review introduction of "constructive criticism" is not bearing the weight it's trying to hold.
It's already been said evolution discussions are mainly to proof the proposal, hardening it against omission, mistake and misdirection. Author silence on an issue should mean confidence in the proposal on point; it's good for authors to let the proposal speak for itself.
Still, as with testing, the question is how you know when you're done. (Exhaustion is not the best measure.)
Consider the analogy of law: there, only when the issue is ripe should courts decide things. Ripeness in that context means there is a concrete controversy, the facts and law at issue have been sufficiently developed, and delaying a decision would be a waste.
Sometimes timing matters most: when later relief would be pointless, courts address even under-developed controversies.
Concreteness means decisions should be as narrow as necessary for the present need, avoid deciding future aspects or abstract aspect. Extensions should be included only if there's real consensus that it's better to include the larger issue because there's really no likelihood of another decision, and others would benefit from relying on the broader scope.
When is a proposal sufficiently developed? Continuing the analogy, any language design or implementation principles should be raised, and the facts would be particular use cases. Where the issue is usability, the cases would include impressions/significance of those cases by representative sample of the audience. As in testing (for software or medical devices), impact matters: even rare incidence of catastrophic consequences can block a feature, and stakeholders can be key to future success.
Finally (and again like testing) you can be complete but wasteful - duplicating effort, not isolating distinct issues or connecting independent ones, focusing on the doable or seeable rather than the important, etc. So ripeness as a principle needs relevance and economy to be sweet and avoid rot -- which again mean people might not respond when issues have been sufficiently raised, or might need a few interactions to surface the crux of an issue.
Discussions and decisions will be unwieldy in many cases -- when they are matters of taste, or require trade-off's or assembling multiple perspectives, etc. Even a ripe and clean decision can involve incommensurable values and future predictions. But still, those decisions need making.
For reviewers to avoid needless umbrage and contribute (as needed), they will have to actively drop natural but misplaced assumptions about advocacy and contest, orient themselves around finding gaps in the proposal or the understanding of its significance, avoid repetition and misdirection, and adopt a belief in the good faith of other participants, the author, and the deciders.
The Swift Evolution Process [1] provides concrete questions for proposal reviewers included in the start of every review thread. But to really orient reviewers to the difference in focus and progress of proposal discussions, it might not be enough to say, "The goal of the review process is to improve the proposal under review through constructive criticism." Advocacy is natural but misplaced here, so up-front elaboration of what constitutes a complete or productive review might help people find the best way to contribute. Also review managers might consider mid-stream ripeness assessments to identify hot spots or gaps, timing and significance, in order to focus further discussion and model reviewer considerations when participating.
[1] https://github.com/swiftlang/swift-evolution/blob/main/process.md