Users learn to select items in small batches because larger selections take disproportionately longer or fail.
The workaround becomes folklore and nobody raises it, so the cost never appears in a ticket.
Per-item cost that scales with everything the interface shows for that item: counts, facets and columns recomputed for each one.
Past a few dozen items the total crosses from slow to unusable, and the point where it crosses depends on how much the default view is showing.
Trim the per-item query cost by auditing what the default view computes, and cap selection sizes where the operation cannot be made cheaper.
Measure the operation at 20, 50 and 100 items before and after, so the improvement is a number rather than an impression.
A few dozenitems is where it crosses from slow to unusable, and that point moves with what the view computes
What the logs said
timings operation time grows faster than the selection size; step change past ~50 items system report default view computes counts and facets per selected item verdict failure mode THREE: per-item query cost, multiplied fix trim the view, cap the selection where needed, retest at 20/50/100