[x-yuri]

1) из глобальных переменных нужен только один нейм спейс. Все остальные нейм спейсы и переменные внутри главного. Это однозначно - иначе при расширении могут возникнуть траблы. В лице нечайного изменения сторонним модулем кому нибудь нужной глобальной переменной.

и толку от этого неймспейса, если он по сути становится новой глобальной областью видимости?

2) Один компонент один класс/обьект. К примеру в одном обьекте можешь разместить информацию о бизнес обьекте, и методы модификации этой информации. Помоему этот паттерн эксперт называется. Я стараюсь им максимально пользоваться. Желательно чтобы разные компоненты были как можно меньше связаны.

не нашел такого паттерна и похоже, что речь идет о том, что следует стремиться к слабой связанности (coupling) и сильной связности (cohesion). Я бы только добавил, что надо задумываться о необходимости связей, а не избегать их любой ценой. Потому что есть обратная сторона медали: чем меньше связей, тем сложнее код.

5) Желательно разбить всё приложение на 3 части пресловутый MVC. Это облегчит сопровождение.
А) слой Present ответственный за интерфейс.
Б) слой ответственный за логику самого приложения
В) Слой ответственный за данные. (мне он нужен редко если
честно, так как я стараюсь групировать данные и методы в бизнес слое)

приведи пример приложений, где это нужно

Это свёртыванием слоёв называется, и это нормальная. практика. Так что не надо ля-ля )))

где об этом можно почитать?

6) Инициализируй все компоненты из которых состоит приложение в одном месте.

почему мне не достаточно знать, где что инициализируется, почему мне нужно засунуть это в одно место?