Glad to be a help,
1.) An example could be to create an event, assign a method to it and then later if you determine it applies you can invoke it. Another usage would be to create the event and not assign it, but call it. Then later determine if you should have some code assigned to it, these facilities enable you to write logic in a way that allows a generic interface.
2.) Basically I would give my reasonology as this: with the code in the controller I am free to keep the pawns code related to direct interactions / animations while retaining all the boilerplate logic at the controller level. For me it is more intuitive this way, I then utilize a behavior tree variable that I use to interchange the root behavior for the various pawns invoking the controller.
3.) We can go further, we can add components dynamically that change the implementation of the base class using the dispatch system.
But most importantly, keep it simple when you can, reserve complexity for complex problems that you solve using small discreet simple solutions.