Скорее всего, из-за заявленных гарантий согласованности и причинности .
Когда операция поиска и изменения включает поиск по ключу осколка, известно, что вся операция может быть выполнена на одном осколке (или, технически, ноль или один осколок), поскольку ключ осколка однозначно определяет осколок, содержащий данные с этим ключом осколка. Другими словами, вся операция может быть направлена к одному набору реплик, который будет выполнять поиск и изменение с гарантиями согласованности и причинности, получаемыми из набора реплик в целом.
Без ключа осколка в условиях , запрос может включать данные, хранящиеся на нескольких шардах. Запрос на чтение, не связанный с ограничением по ключу осколка, отправляется всем осколкам, которые независимо возвращают совпадающие документы, которые затем собираются в единый набор результатов маршрутизатором mongos (это также известно как чтение с разбросом-сборкой). При выполнении поиска и изменения обновление также должно быть отправлено на все шарды, у которых есть совпадающие документы, которые могут быть несколькими шардами. Без распределенного координатора записи между шардами могут быть несовместимыми. Такой распределенный координатор не существовал до сервера 4.2, когда поддержка транзакций была реализована в сегментированных кластерах.
Я предполагаю, что в будущем ограничение на включение ключа сегментов в поиск и изменение может быть ослаблено, если поиск and-modify выполняется в транзакции, поскольку транзакция уже выполняет распределенную координацию (хотя отдельные обновления все равно были бы более эффективными, если бы ограничивались одним сегментом).