Suponha que eu tenha uma classe 'Aplicativo'. Para ser inicializado, são necessárias algumas configurações no construtor. Vamos supor também que o número de configurações é tão grande que é interessante colocá-las em uma classe própria.

Compare as duas implementações a seguir deste cenário.

Implementação 1:

class Application 
{
   Application(ApplicationSettings settings) 
   {
       //Do initialisation here
   }
}

class ApplicationSettings 
{
   //Settings related methods and properties here
}

Implementação 2:

class Application 
{
   Application(Application.Settings settings) 
   {
       //Do initialisation here
   }

   class Settings 
   {
      //Settings related methods and properties here
   }
}

Para mim, a segunda abordagem é muito preferível. É mais legível porque enfatiza fortemente a relação entre as duas classes. Quando escrevo código para instanciar a classe Application em qualquer lugar, a segunda abordagem fica mais bonita.

Agora, imagine que a própria classe Settings, por sua vez, tenha uma classe similarmente "relacionada" e essa classe, por sua vez, também. Vá apenas três desses níveis e a nomeação da classe fica fora de controle no caso 'não aninhado'. Se você aninhar, no entanto, as coisas ainda permanecem elegantes.

Apesar do exposto, li pessoas dizendo no StackOverflow que classes aninhadas são justificadas apenas se não estiverem visíveis para o mundo externo; isto é, se eles forem usados apenas para a implementação interna da classe que contém. A objeção comumente citada é o tamanho do arquivo de origem da classe, mas classes parciais são a solução perfeita para esse problema.

Minha pergunta é: por que somos cautelosos com o uso "publicamente exposto" de classes aninhadas? Existem outros argumentos contra esse uso?