В общем по результатам исследований проблемы:

1. Проблема наблюдается только в PHP (Драйвер Microsoft SQL driver for PHP последней версии), повторить ситуацию в SSMS я не смог. Вообще не смог вызвать ни разу указанную ошибку, даже специально возвращая данные в триггерах.

2. Set nocount on, так же как и disallow results from triggers = 0 не помогают, так как никаких возвратов из триггеров, или из процедур, вызываемых из триггера, у меня нет, все проверил. При включенном disallow results from triggers = 1 SSMS сразу будет выдавать исключение при возврате данных из триггера, и в данном случае его (исключения) нет.

3. Как выяснилось, минимальный фрагмент на PHP, генерирующий ошибку, состоит из трех действий:

а) открыть запрос А, выдающий несколько строк
б) сделать fetch одной записи из запроса А
в) выполнить процедуру Б, собственно добавляющую данные и вызывающую ошибку.

Без открытого запроса А и прочитанной первой строки никаких ошибок не генерируется. Запрос А должен достигать определенной сложности по исполнению, при уменьшении сложности запроса сначала ситуация становилась нестабильной (Иногда появляется ошибка, иногда нет), при дальнейшем упрощении ошибка исчезала.

Предполагаю, что проблема в том, что исполнение запроса для получения следующих строк идет асинхронно с основным потоком, т.е. одновременно с исполнением процедуры Б, которая каким-то боком воспринимает возвращаемые запросом А данные как возвращенные триггером.
Буду рад комментарию знающих механику происходящего людей, сам в этом не особо разбираюсь, увы.

Рекомендация (которая помогла):
Не выполнять процедуры, вызывающие изменения в данных, одновременно с наличием открытых и не до конца прочитанных запросов. Либо делать это в разных транзакциях. (Хотя последнее надо бы проверить, что-то я уже сомневаюсь).
То есть достаточно поменять шаги А, Б и В местами, и никаких ошибок больше не возникает. Либо между Б и В добавить чтение всех оставшихся записей запроса А.

Почему должен? В чем сложность в том же SSMS написать


Работает на ура...
Ну да, технически могут быть dirty reads, ну и фиг с ними.
И главное технически обеспечить запрет подобного действия (Если оно вдруг запретное) на уровне драйвера не просто легко, а очень легко. Не сделали же.