Most of the time collectibles do not need to know who or what it is interactiing with. They are meant to exists until told to be destroyed.
The logic to handle what happends to the collectible actor can be placed in an actor component applied to the possessed pawn with a bind to the owners overlap event. This component can handle the cast to the base collectible class and get what ever it needs. Tags can also be used to further filter the collectibles and execute more logic if needed.
Interfaces could be used over casting to the base class, but IMO it depends.
Same somewhat applies to interactive props, but here interfaces are usually needed to decouple the classes. From the point of view of the possessed pawn, when E is pressed the pawn traces and tries to call the interface on what ever it hits. If the actor being hit has the interface then it will execute an event. Neither needs to know who / what / etc…
This will allow you to set basic functionality in the base class and overrite in the child classes for added functionality.
So you can have a base class (a door) that has an event that changes the states opens / closes; a child can overrite the event to only trigger when a possessed pawn is overlapping or < X distance and another child that will only trigger if a specific component was hit. Maybe a door has to check if certain number of items have been collected or another won’t open if the player has certain item… etc
The main point of all this is to have as much as possible be event driven.
In this specific case I suggest you remove all this from the coin class. Add an actor component to your pawn that is able to detect if it overlaps a coin, if it did then destroy it on overlap and do the rest.
Here is another approach from Epic: Build Gameplay Mechanics for a Collectible Item Game | Course
I’m sure you’ll find many ways to make this work.
Hope this helps.