¿Por qué siempre tener interfaces de implementación únicas en capas de servicio y dao?

He trabajado/visto algunos proyectos de aplicación web spring-hibernate que tienen tantas interfaces como hay clases reales de servicio y dao.

Siempre pensé que estas dos son las principales razones para tener estas interfaces de implementación únicas:

1. El resorte puede cablear la implementación real como dependencias en una clase dada (acoplamiento suelto)

   public class Person { 
       @Autowired 
       private Address address;
   
       @Autowired 
       private AccountDetail accountDetail;
   
       public Person(Address address, AccountDetail accountDetail) 
       { // constructor
   

2. Durante las pruebas unitarias, puedo crear clases simuladas y probar una clase en aislamiento.

   Address mockedAddress = mock(Address);
   AccountDetail mockedAccountDetail = mock(AccountDetail);
   Person underTestPerson = new Person(mockedAddress, mockedAccountDetail); 
   // unit test follows
   

Pero, últimamente, me di cuenta de que:

Spring puede cablear clases de implementación de concreto como dependencias:

public class Person { 

@Autowired 
private AddressImpl address;

@Autowired 
private AccountDetailImpl accountDetail;

public Person(AddressImpl address, AccountDetailImpl accountDetail) { 
// constructor

Marcos simulados como EasyMock también pueden simular clases de concreto

AddressImpl mockedAddress = mock(AddressImpl);
AccountDetailImpl mockedAccountDetail = mock(AccountDetailImpl);
Person underTestPerson = new Person(mockedAddress, mockedAccountDetail); 
// unit test follows

También, según esta discusión, creo que el resumen es que dentro de una sola aplicación, las interfaces son en su mayoría sobreutilizadas probablemente por convención o hábito. Por lo general, tienen mejor sentido en los casos en que estamos interactuando con otra aplicación por ejemplo slf4j utilizado por muchas aplicaciones en todo el mundo. Dentro de una sola aplicación, una clase es casi tanto una abstracción como una interfaz.

Entonces, mi pregunta es por qué todavía necesitamos Interfaces y luego tenemos implementaciones únicas como las clases *ServiceImpl y *DaoImpl y aumentamos innecesariamente el tamaño de nuestra base de código. ¿Hay algún problema en burlarse de clases concretas que no soy consciente.

Cada vez que he discutido esto con mis compañeros de equipo, la única respuesta que obtengo es que el servicio de implementación y las clases de dao basadas en interfaces es EL DISEÑO que todo el mundo sigue: mencionan las mejores prácticas de primavera, OOP, DDD, etc. Pero todavía no entiendo una razón pragmática detrás de tener tantas interfaces dentro de una aplicación aislada.