This question is on the border of "primarily opinion-based". There are no right or wrong solutions to software architecture problems. Only solutions that work for you or solutions that don't work for you.

However, I would need to point out two advantages of events over direct references:

1. Single-listener scenarios might not stay single-listener scenarios forever. Already having an event allows you to add additional listeners with very little effort.
2. Having events allows you to have two objects communicate with each other without having a direct dependency on each other on the sourcecode level. This is particularly useful when you use assembly definitions to speed up compilation times. The fewer dependencies you have between classes, the more you can benefit from having lots of small asmdef's.

This question is on the border of "primarily opinion-based". There are no right or wrong solutions to software architecture problems. Only solutions that work for you or solutions that don't work for you.

However, I would like to point out two advantages of events over direct references:

1. Single-listener scenarios might not stay single-listener scenarios forever. Already having an event allows you to add additional listeners with very little effort.
2. Having events allows you to have two objects communicate with each other without having a direct dependency on each other on the sourcecode level. This is particularly useful when you use assembly definitions to speed up compilation times. The fewer dependencies you have between classes, the more you can benefit from having lots of small asmdef's.