Вот согласен лишь насчёт тестирования

О срач про эвенты

Зачем дёргать сервис из "модели", если можно вынести целиком всё в метод сервиса?

И обновление модели и вызов другого сервиса)

Эвенты неявное говно и не должно использоваться для БЛ

Уведомлять пользователя, писать в историю пожалуйста. Но взаимодействовать с критическим слоем БЛ не должно

И дело не только в тестировании

1) Просто когда проект набирает некий объем - ты напрочь забываешь что у тебя есть какие то эвенты и они что то делают.
2) Если в команду приходит новый разработчик - он просто охренеет от того что достаточно просто сохранить модель и все происходит "за кадром"

Ну я про уведомления и говорил

Да вы просто прилиплили к юиишным эвентам. Можно же в модели регистрировать события в нужных местах например $this->addEvent(...), а диспатчить в репозитории при сохранении например? И что вы тогда протестировать не сможете? И так сложно будет их найти в коде?

Я не читал, высказал свое мнение

Я не сказал, что работать с логикой на событиях нереально или невозможно.

Просто это без особой необходимости усложняет поддержку.

В будущем может запутать всё настолько, что события придётся выпиливать, и это будет сложно и дорого.

Но я не отговариваю вас, вовсе нет. Магия граблей в том, что пока сам на них не наступишь, ничему не научишься)

Мне в школе и goto был норм, пока мои программы не превышали сотню строк..

Окей, я не хотел разводить тут спор) Но когда позвонит заказчик и скажет, что при сохранении товара с измененным количеством товара нужно выполнить несколько дополнительных операций, а возможно это будут задачи которые в фоне нужно покрутить то придется призадуматься))

Окей.

1. Вынесли всё в метод сервиса. updateStockItem().
2. Вызвали метод сервиса в контроллере.

Где здесь необходимость в событиях?

1 - В объемном проекте всегда найдется то, что легко напрочь забывается. Спасает от этого описание концепций, применяемых в проекте, и грамотное следование этим концепциям.
Сами концепции, при этом, могут быть самыми разными - и с использованием ООП, и без. С использованием ДИ или с синглтонами и фасадами - это не критично.
2 - Это нормально. Это неизбежные издержки замены разработчика. Особенно веселят такие товарищи, и 5 минут на код не посмотревшие, а уже охреневающие.
Нормальный разработчик, при этом, не будет ни охреневать ни умничать, а разберется в причинах именно такой архитектуры, в том числе и исторических, и начнет работать.

Уведомление тоже метод сервиса отправить должен?

Почему бы и нет?) Раз это входит в задачу

Если уведомлений всяких много, можно для них отдельный сервис или хелпер сделать.

Но это уже от контекста зависит.

Их несколько типов: мыло юзеру, телега админу

Есть в Yii2 такое поведение - TimestampBehavior.
В одну строку кода добавляет функциональность - устанавливает поля created_at при создании или updated_at при изменении объекта.
Расскажите, как Вы сможете реализовать эту функциональность без событий?

Задача заключается не в том чтобы обновить количество, а что когда в товаре меняется количество нужно произвести манипуляции. Да, можно в сервисе написать if и написать кучу добавлений в очередь и прочей логики. Но это придется писать в каждом методе, добавление, редактирование и прочее. А у нас еще может быть пачка задач, залить картиночку на s3, сгненерить превьюхи если была залита, перестроить индекс на фронт и прочая и прочая муть. И на что в итоге будет сервис похож и сколько нужно будет других сервисов включить в этот сервис?