Другие недостатки паттерна, которые я вижу:

1. Нельзя вынести интерфейс и подменить одну реализацию синглтона на другой (нарушение DIP)

2. Паттерн синглтон нарушает SRP, потому что отвечает дополнительно за создание и удаление самого себя. Это может усложнить разработку, если жизненный цикл синглтона не соответствует жизненному циклу программы

3. Использование синглтонов, усложняет тестирование, поскольку классы, использующие синглтоны, имеют неявные зависимости

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

Например, это может быть плагин аналитики, в которую нужно отправлять данные или универсальная аудиосистема, которая отыгрывает звуки, но не EnemySpawner, который используется только для EnemySystem.

Еще обязательным условием использованием синглтона является то, что синглтон должен существовать весь жизненный цикл работы программы, и к нему всегда должен быть доступ.

Таким образом, для работы с бизнес-логикой рекомендую использовать паттерн Dependency Injection (фреймворк Zenject/VContainer). Это даст возможность переиспользовать, тестировать и подменять реализации классов, фокусируясь на решении задач, а не выстраивании архитектуры (рис. 3). А синглтоны использовать только в тех случаях, когда нужно получать универсальный модуль из разных точек программы, и этот "волк" живет все время приложения.