Supongamos que tengo una clase 'Aplicación'. Para ser inicializado se requieren ciertas configuraciones en el constructor. Supongamos también que la cantidad de configuraciones es tanta que es convincente ubicarlas en una clase propia.

Compare las siguientes dos implementaciones de este escenario.

Implementación 1:

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

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

Implementación 2:

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

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

Para mí, el segundo enfoque es muy preferible. Es más legible porque enfatiza fuertemente la relación entre las dos clases. Cuando escribo código para instanciar la clase de aplicación en cualquier lugar, el segundo enfoque se verá más bonito.

Ahora imagínense que la clase de Configuración en sí tenía una clase similarmente "relacionada" y esa clase también lo hizo. Ir solo en tres de esos niveles y el nombre de la clase se sale de control en el caso 'no anidado'. Sin embargo, si anidas, las cosas siguen siendo elegantes.

A pesar de lo anterior, he leído personas que dicen en StackOverflow que las clases anidadas se justifican solo si no son visibles para el mundo exterior; es decir, si se usan solo para la implementación interna de la clase contenedor. La objeción comúnmente citada es hinchar el tamaño de contener el archivo fuente de la clase, pero las clases parciales son la solución perfecta para ese problema.

Mi pregunta es, ¿por qué desconfiamos del uso "expuesto públicamente" de clases anidadas? ¿Hay otros argumentos en contra de tal uso?