Синоним слова синглтон будет "глобальная переменная". Уже лет 50 все книги-буквари по программированию пишут одно и то же : "Избегайте глобальных переменных". Люди действительно стали избегать — практически везде, где раньше были глобальные переменные, выросли синглтоны. Что интересно — все проблемы остались. Фактически, такой синглтон просто замыкает самые разные контексты и является ни чем иным, как способом управления депенденсами, негибким, проблемным и очень непредсказуемым.

Есть простой подход, который позволит понять, о чем идет речь — заменяем слово "синглтон" на "глобальная переменная" и смотрим, что же изменилось. Обычно речь про единственный экземпляр какого то типа. Но, извините, синглтон и единственный экземпляр это немного разные понятия. Синглтон требует, что бы была глобальная точка входа. Более того, должна решаться какая то проблема, например — долгая инициализация, засорение глобального неймспейса и тд.

Вобщем, получается так, что для паттерна Синглтон есть почти одно применение — глобальный объект навроде App.

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

Вообще говоря, мой подход с паттернам примерно такой — сначала решить задачу, а потом переводить решение в код. Если на втором этапе возникают ассоциации с паттернами, то, как вариант, можно посмотреть варианты решения просто для уточнения деталей. Писать или не писать конкретный паттерн явно в коде это вообще дело десятое. Паттерн вообще должен решать одну или несколько реальных проблем и, при этом, должен хорошо вписываться в глобальный дизайн решения. Если этого нет, то паттерн есть просто баззворд.
За употребление паттернов на первом этапе, то есть на стадии поиска и принятия решения, считаю, надо бить по рукам, головам, почкам и даже ниже пояса любыми способами — явными, неявными, прямыми, косвенными, симметричными, ассиметричными и тд и тд и тд.

Если ограничить применение Синглтона именно глобальным объектом App, то, внезапно, из этого можно извлечь целый ряд профитов. Например можно ввести просто адскую диагностику средствами REPL. А можно менять стратегии персистанса глобального состояния. Забрать у классов эту обязанность и переложить её на фремворк приложения — пусть он решает, где и как будет сохраняться состояние приложения и будет ли вообще сохраняться. Что же должно храниться в этом объекте ? Хранить нужно собтсвенно состояние, время жизни которого
1. равно времени жизни экземпляра приложения
2. больше времени жизни экземпляра приложения

Собственно всё.

var x = new MegaDatabaseClass();

   using(var x = OperationEx.Create<Concrete1>()) {
          x.Load(args1)
          .Proceed1(args2, x => Predicate1)
          .Proceed2(args3, x => Selector1)
          .Proceed3(args4)
          .Save(args5);

      return x.Result;
   }

var operation = new Operation
{
   args1 = ...,
   args2 = ...,
   ... 
   args5 = ...,
};

operation.Run();

// Видишь синглтон?
// Do work using connection
void boo()
{
            using (var connection = CreateConnection())
            {                
              bla. bla. bla.
              ...
              bla.
            }
}
//  — Нет!

// — И я не вижу. А он есть!
void foo()
{
        using (var scope = CreateScope())
        {
            // Do transactional work
            boo();
            scope.Complete();
        }
}

А>// Видишь синглтон?
...
А>// — И я не вижу. А он есть!
А>