Смотрю, флейм никак не остановится.
Давайте уж говорить конкретно - не только про выигрыш, но и про затраты.
В условиях, когда приложение развивается по диздоку, который пересматривается постоянно (конкуренты, желания пользователей, тестирование игровых технологий и пр.), мы не знаем заранее, где и когда нам потребуется что-то настраивать в зависимости от параметров приложения, поэтому, если хотим остаться в рамках корректного ООП (т.е., отдаем всем объектам только то, что им положено знать), мы влетаем в очень большие издержки по модификации кода каждый раз, как только появляется необходимость передать новый параметр сверху в самый низ.
Вариант с объектом-оберткой для всех параметров AppSettings (или как-то так), который мы закладываем на этапе проектирования и передаем всем сверху вниз через конструкторы, позволяет минимизировать затраты по доработке, но нарушает правило, что каждый получает только то, что должен, значит корректным признан быть так же не может.
ЗЫ. По поводу реиспользования кода - мне искренне хотелось бы посмотреть на реиспользование окна банковских операций по переводу валюты соцсети в игровую валюту в приложениях, не связанных с социальными сетями. Но это так, реплика из зала.