Well, one thing to consider here is side effects. As implied by the name, VTasxk<Suspend|Resume>All prevents context switches to ALL ready tasks which by definition includes tasks that are not affected by the sync issue in question.
In this here thread:
we had a similar issue, regarding the invasiveness of critical sections. For now, I’d like to liken the suspend/resume mechanism to the task-level counterpart of critical sections: It does have a global side effect.
Thus, only use global suspension/resume if there is a very good reason for it, analogous to the critical section. In real time architectures, our goal is to give every thread of execution (tasks or ISRs) the highest possible responsiveness and throughput allowed by the restrictions of the hardware and the OS. Employing any mechanism that has global side effects in return for only providing “local synchronisation” is always bad in first approximation unless absolutely required.
In my understanding, both the critical section and the global suspend/resume APIs should be flagged as something like “privileged APIs by convention,” meaning that they were originally introduced to be used by the OS itself and exposed only for application that do require a side effect on the entire system (and could thus be informally labelled “OS extensions”).