Тем что он своего рода реализация паттерна observer. Он не для расширения возможностей других объектов нужен, а для слушания их состояния/изменения.
Тоесть один объект кидает событие, а эвент его обрабатывает. Например та же авторизация, действие авторизации рождает событие "auth.success" (успешная авторизация), на это действие мы хотим провести дополнительные действия, например зафиксировать в логе авторизацию и направить письмо пользователю об авторизации со сменой IP. За авторизацию отвечает плагин Users, а вот за фиксацию лога и отслеживание политики безопасности отвечает плагин Security.
Если мы разместим логику не в эвенте, мы сделаем эту логику частью плагина авторизации, но по факту за информацию отвечает не плагин авторизации, а сторонний, который не вмешивается в работу пользовательского плагина на этапе авторизации, а лишь слушает его состояние с целью выполнения собственного действия - "пользователь авторизовался, необходимо инициировать отправку уведлений и зафиксировать в журнале"
У тебя же в евентах расширение не поведения блоков, а расширение конфигурации по наличию этих самых блоков, что не совсем является предназначением паттерна обсервера, ведь для корректной регистрации блоков, а главное возможности например получить весь список не в форм виджете, тебе необходимо вызывать событие в конструкторе менеджера (А в твоем случае это используется для расширения базового конфига плагина, в одном лишь методе форм менеджера). Против прямого расширения к примеру той же конфигурации через фасад Config из boot своего плагина, аналогично как это делается с коннекшенами к БД, кешу.
\Config::set('reazzon.editor::toolSettings.newBlock', [
'raw' => [
'class' => 'RawTool'
],
]);