Wow big PR thanks for tackling this!
I think we first need to solve the factorization of the attribute extraction logic.
To me this should be lazy and central.
I suppose we need to put the attributes in a _controller_attributes request attribute, that should be computed by a service that listener that need the info should require to compute _controller_attributes if it's not set.
Or another design if you have another proposal of course!
Would you like to give it a try in a separate PR?

In case it needs to be lazy and central, it might be a good idea to incorporate it in the Routing component.

It would make it possible for the attributes to be placed in an already existing cache, whichever configuration format the developer uses to configure their routes. Plus it would make the following possible when attribute support is disabled:

return function (RoutingConfigurator $routes) {
    $routes->add('foo', '/foo')
        ->controller([BlogApiController::class, 'show'])
        ->attributes([
            new Cache(maxage: 15),
            new Template(template: 'templates/foo.html.twig')
        ])
    ;
};

See https://github.com/sensiolabs/SensioFrameworkExtraBundle/issues/140 for this being requested 10 years ago.

Routing is mostly unaware of the concept of controllers so I wouldn't add to it. HttpKernel is just fine for that to me.

Thank you very much for all the effort you've put into this PR!

One reason why FrameworkExtraBundle should be deprecated was that Symfony already has a replacement for the ParamConverter mechanism:

https://symfony.com/doc/current/controller/argument_value_resolver.html

Now in your PR, I see that ParamConverters have been resurrected. Can you please have a look if you can build those attributes with argument value resolvers instead?

See #45457 for the controller attribute mechanism suggested by Nicolas :)

The best practices docs tells us not to use the @Template annotation.

It makes me question whether Template should even be migrated to an attribute ?

Also, I would not migrated the Security attribute as is. The implementation of this attribute is currently a hack, as it does not rely on triggering the authorization system to perform the security check (instead, it duplicates part of that system, which broke when switching to the new security system).
The best practice for using that attribute is to restrict yourselves to using is_granted inside the expression (or to switch to IsGranted for all cases where it can be used, as that attribute does not hack the authorization system).

To me, this should rather be left out, adding a few advanced features to IsGranted:
The one I would need personally is having a subject_expression feature, allowing to use ExpressionLanguage to build the subject being voted on (but with a better approach than Security where we have clashes between controller argument names and built-in variables of the expression) when we need a more complex vote.
Another one that could be needed is a way to specify that the permission being checked is an expression for ExpressionVoter (but this may be supported already on PHP 8.1 when using attributes rather than annotations, but using new Expression)

@codedmonkey would you be up to resume this work on top of #46001? It'd suggest splitting this PR in many, one per attribute.
Closing here meanwhile for history.

I'll see what I can do :)

Cool thanks, I'm looking forward to your PRs 🙏
I already started with #[Cache], please check # #46880.

I implemented #[Template] in #46906 and #[IsGranted] in #46907
I won't be able to work on the other ones before August so feel to follow up with the other attributes!

@nicolas-grekas I think you've got them all covered since the ParamConverter and Security annotations have been discusses and rejected by the community. Thank you for all the hard work :)