Нужно ли всегда по максимум отказываться от MonoBehaviour?

Хотя магические методы монобехов отжирают производительность, что видно на астраномических цифрах, типа 10.000 Update, дело вообще не в оптимизации. Те кто понимают, в чём смысл MonoBehaviour и не используют его где не попадя, те, как не странно, понимают что они делают и не разбазаривают производительность на чепуху, типа поиска одного и того же объекта на сцене каждый кадр по несколько раз и МНОГОЕ другое. Большая или маленькая игра, не важно, те кто не могут хорошо написать маленькую, тем более всё горит красным пламенем на масштабах побольше. Не то что в "маленькой" игре, даже в одном скрипте, даже в паре строчек кода можно убить fps, для избежания чего используют профайлер.

GameObject это базовый объект сцены, а Component (коим является MonoBehaviour) его элементы логики/данных, обеспечивающие положение и взаимодействие с другими объектами сцены (физика), а так-же визуализацию. Этим можно полностью и обойтись, используя его как провайдер, что и происходит например, когда используешь LeoEcs. Более того, не всем скриптам нужно быть MonoBehaviour, который наследуется от Behaviour умеющий быть enable/disable но не имеет магических методов, а например RigidBody наследуется от Component, в котором нет вообще никаких плюшек, он просто умеет быть частью GameObject.

Кроме того, если следовать принципу единой ответственности, коему должны следовать все, то от количества компонентов на GameObject можно рихнуться! Уже наличие 5+ компонентов превращает объект в какую-то свалку в которой нужно капаться и сворачивание никак не спасёт, этот инспектор просто не хочется открывать. Программисты свалки не любят не потому, что брезгливые, а просто потому, что порядок это единственный способ не рихнуться и бросить всё в печь.