I'm sorry but I don't think this is an idea we should pursue.
It forces tight coupling to the component by inheritance and relies on pure conventions that happen to be what I call dead-ends: as soon as you want to listen to many events, you need to unlearn what you had to learn to use this class, you then need to learn about subscribers, and best of all, you are forced to change the inheritance chain - thus break BC.

[edit: this comment is now obsolete]

It forces tight coupling to the component by inheritance and relies on pure conventions that happen to be what I call dead-ends: as soon as you want to listen to many events, you need to unlearn what you had to learn to use this class, you then need to learn about subscribers, and best of all, you are forced to change the inheritance chain - thus break BC.

For the same reasons, we could ban the abstract Voter class from the security component for instance. Yet, classes like these remove the need for boilerplate that looks the same in 80% of the cases.

Also, developers can look into this class and learn how they can build subscribers without it. The reflection part aside, it's pretty straightforward.

Voter doesn't use reflection. It's just a base abstract class.
The proposed one provides conventions by reflection.

All this is exactly the same as writing:

    final public static function getSubscribedEvents(): array
    {
        return [MyEvent::class => ['__invoke', 0]];
    }

Saving writing this is not worth the drawbacks to me.
If you want to save writing this, a maker would do it without the drawbacks.

What about a new interface for single-event subscription?

interface EventListenerInterface
{
    public static function getEventName();
    public static function getMethodName();
    public static function getPriority();
}

and with auto-configuration would make the current event listener approach even easier maybe?

Related to #33485 (comment), the getMethodName could also be useless if the event listeners already support invokable classes.

Talking with @nicolas-grekas on Slack, their architectural objections can be removed using traits, done!, so let's focus on the teachability objections now :)

I will add more tests when the objections have been removed, I hope that :)

If you're ok with my last review, we could name the trait InvokableEventSubscriberTrait

@nicolas-grekas comments addressed where possible, how does it look to you now?

Update

Removed getEventName and getPriority methods, so you'll use this trait for one exclusive purpose, the most common on app side:

class MyEventSubscriber implements EventSubscriberInterface
{
    use InvokableEventSubscriberTrait;

    public function __invoke(MyEvent $event): void
    {
        // ...
    }
}

If it does not fit your needs, because the event name is not the FQCN or it has a different priority, then you should not use this feature and would implement the getSubscribedEvents() method directly.

For using this you have to use a given trait + implement a given interface + eventually declare some static properties - vs implementing getSubscribedEvents, I'm not convinced it's worth the complexity.
Also this involves reflection which RegisterListenersPass already uses for similar validation...

Given this basically allows for autoconfigured event listeners, couldn't we just add a marker interface instead? That could allow to keep the reflection-based logic in the compiler pass only and could, I think, reduce the learning curve.

@chalasr I'm personally against adding a new abstraction when we already have all we need. That'd be another option, thus another choice to make for ppl, but learn about them before, document it, etc.

The more we talk about this one, the more I think we should not add this to core. I'm now 👎 .

Let's close then, it's not worth it for me anymore.