Nice catch. Can you please add a test case so that we're reminded about that behavior?

Reviewing this feature, I realized that the RegisterListenersPass which registers event listener does not actually implement PriorityTaggedServiceTrait! https://github.com/symfony/symfony/blob/5.4/src/Symfony/Component/EventDispatcher/DependencyInjection/RegisterListenersPass.php#L94

Now this

1. obviously makes my PR obsolete
2. begs the question whether the listener should be changed to use the trait? 😅

I don't quite get why I would configure an event listener by attribute but set the priority via method call. If I use the attribute, why don't I use the attribute for everything?

I realized that the RegisterListenersPass which registers event listener does not actually implement PriorityTaggedServiceTrait!

Oh indeed, priority is managed by the EventDispatcher at runtime.

I don't quite get why I would configure an event listener by attribute but set the priority via method call. If I use the attribute, why don't I use the attribute for everything?

Yeah thats a good question, and maybe why this has never been added to event listeners. As far as I understand, this was added in #33628 to support priority for services that were tagged through (interface) autoconfiguration. I guess this has never become relevant for event listeners because one could use the EventSubscriber pattern in that case (which is not available for e.g. security voters).