This is the interesting part here.

In a real application, these services would be used in other services, in console commands, etc. You cannot remove them.

I agree than in a real app large app I would explicitly defined at least the slugger service. However, it's not necessary in this sample RAD app and it shows how the new controller system can be used (for RAD only of course).

Just some hints:

• those services hey are used in other services here (@markdown is used in @app.twig.app_extension)
• an advantage of using autowiring is if you change signature of the constructor of the AppExtension or if you rename the markdown service, you don't need to update your config
• if the service using @markdown is itself autowired the @markdown is automatically injected (@app.twig.app_extension)
• defining explicitly the service (adding back the @slugger definition for instance) doesn't break anything (the named service will be detected and injected everywhere the autowiring service is defined)
• by convention, all services created by the autowiring system are accessible using the autowired.the\fqn name (but it's better to name them explicitly if you want to access them). Here there is a @autowired.AppBundle\Utils\Slugger service.

Btw, console commands can be autowired the same way than controller, I'm adding an example right now.

IMO, keeping the controllers in Controller is better, even if you rely on a special loader aware of the way they are registered as services.

Yes I've opened an alternative PR for that. But I think I'll do it even in the default setup of the bundle. It will be more familiar for Symfony developers (and it seems to be a general concern).