Переосмысление SOLID: почему традиционные принципы проектирования не работают при разработке игр

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

Система сообщений или “мягкая связь” между компонентами для Unity3D

Само использование рефлексии крайне ресурсоёмко. Выполнение одноразово при инициализации экземпляра немногочисленного набора объектов — допустимо, но рефлексия для каждого подписчика при наступлении каждого события в игре — ужасная практика. Вы сами описали эти события: выстрел, попадание пули, отнимание здоровья и т.д. И это только примитивный набор функционала для тестовой игры. Даже в малом проекте в продакшене сотни связей и вызовов методов других классов, если всё это реализовывать на рефлексии — всё процессорное время будет тратиться на её обработку. (Извиняюсь за тавтологию) Рефелексия — bad practice и используется только в самых крайних случаях, а не тогда, когда Вам лень проверять Event на null. Многое из проделанного — излишне. В интернете множество графиков сравнений скорости работы различных методов вызова функций. Например:
habr.com/post/353780
Здесь ясно описана разница различных методов. Ваш подход уступает в производительности в 55-90 раз. Вы считаете это хорошим результатом?

Система сообщений или “мягкая связь” между компонентами для Unity3D

При включении поддержки .NET 4.5 и использовании C# 6.0 (что уже повсеместно в проектах), можно немного видоизменить код.
До:

if (StartEvent != null)
{
    StartEvent();
}

После:

StartEvent?.Invoke();