K>>3) Почему у некоторых программистов такое отрицательное отношение к глобальным/статическим переменным/классам/методам и паттерну singleton?

А>Глобальные переменные плохи тем, что доступ к ним слабо контролируем. Синглтон-класс — немногим лучше.
А>Для себя вывел правило: синглтон может безопасно существовать в системе, но использующие его модули НЕ должны знать, что это синглтон. Т.е. модуль должен при инициализации получать экземпляр класса MyClass как провайдера требуемого функционала (dependency injection или типа того), но НЕ дложен звать всякие статик-методы типа MyClass::getInstance() или getMyClassSingleton().

Там, где этого легко добиться, то так и надо делать. Но если синглетон должен быть использован где-то глубоко внутри реализации, то, выигрывая в расширяемости, мы проигрываем в сложности кода, так как нам надо будет тянуть все необходимые синглетоны через все иерархии классов, или прийдется создавать что-то типа сервиса именования и все-равно для каждого объекта тянуть глобальный контекст. А это не всегда возможно — есть унаследованный и сторонний код. В общем, избавляясь от одних сложностей, мы получаем другие, не меньшие.
Для себя я использую два правила:
1. Оформлять в синглетон можно только логические подсистемы приложения (что-то типа фасадов, за которыми скрыта обособленная функциональность).
2. Синглетон отвечает только за доступ к функциональности; инициализация и деинициализация соответствующих объектов все-равно должна выполняться явно.

А>Ибо условия задачи могут (и будут) поменяться, и вместо использования синглтона может потребоваться доступ к нескольким разным экземплярам класса MyClass, где бывший синглтон-экземпляр — всего лишь дефолтный вариант. И вычищать логику, опиравшуюся на статик-методы, ой как неприятно и муторно потом.

Ну это вопрос архитектуры. Такое может произойти, но надо всегда взвешивать шансы. Там где это более вероятно, то синглетон конечно использовать не стоит.