Hola de nuevo Carlos,

he borrado el comentario anterior porque creo que no me he explicado del todo bien, perdona 😀.

En el final del artículo hago mención a ésto:

Nota. El servicio decorado queda convertido en un alias del servicio decorador (según la propia documentación de Symfony “The decorates option tells the container that the App\DecoratingMailer service replaces the App\Mailerservice”. Es decir, que si inyectáis el servicio App\Repository\RepositoryA lo que obtendréis es el servicio ya decorado. De este modo, no sería necesario recurrir a los defaults bindings y nos ahorraríamos unas líneas de configuración.

(he ampliado más un poco dicho texto a raíz de tu comentario para que se entienda mejor).

Es decir, que el servicio decorado se convierte en un alias para el servicio decorador, de modo que si estamos inyectando en algún sitio App\Repository\RepositoryA lo que obtendremos es el repositorio decorado, por lo que no es necesario recurrir al binding por defecto que indico en el artículo salvo que… estemos empleando el decorador en distintos servicios como es el caso que estaba comentando de los repositorios.

Es decir, no es posible definir en el services.yaml

App\Repository\RepositoryDecorator:
  decorates: App\Repository\RepositoryA
  
App\Repository\RepositoryDecorator:
  decorates: App\Repository\RepositoryB

de modo que en mi caso tengo que recurrir a ese sistema y prescindir del autowiring:

app.repository.a.stats:  
  class: App\Repository\EntityStatsRepositoryDecorator  
  decorates: App\Repository\RepositoryA
app.repository.b.stats:  
  class: App\Repository\EntityStatsRepositoryDecorator  
  decorates: App\Repository\RepositoryB

En cualquier caso y como bien comentas, mejor repetir líneas de configuración que líneas de código además que creo que este patrón ilustra muy bien los principios open-closed y composition over inheritance por lo que yo lo seguiría aplicando siempre que se de el caso.

Espero haberme explicado ahora mejor y muchas gracias por tu comentario!