I am not sure if I fully understand your example, the additional reference confuses me a little. But in general you can have UBaseClass in C++ that has a TSubclassOf property and a DoSomething() BlueprintImplementableEvent function and you can create a child blueprint in which you assign the actual class reference and implement the event. Then you can access the referenced class and invoke the function through the base class instead of having to cast to the concrete blueprint type.
As @Auran131 rightly stated, this sort of does not matter once you deal with actual instantiated objects since those have to be loaded already. To really minimize the amount of hard references, you have to use soft references and lazy load things as they are needed. What we are discussing is sort of specific to cast nodes and how they are included in the reference chain.
Let’s say you had an interactable actors with two implementations, A and B. One spawns 10 different actors and the other plays a bunch of different sounds and particle effects (imagine anything that references external assets, building up the reference chain). If you player controller was implemented in such a way that it casts the actor to A and then B to determine which actor it is in order to invoke their specific functionality, it would hard reference both of them by default and as a result all of the assets they themselves reference. If you instead cast the actor to their parent C++ class with a generic Interact() function that is implemented in the A and B blueprints, this wouldn’t be the case. If the level only had A interactables, their class would be loaded but not the B class. Obviously, if the level contains both, then both will be loaded but that’s not an issue since you are actually using them.
Basically, the whole idea is to not have a bunch of classes loaded in memory for no reason outside of having them referenced in cast nodes that will not succeed because there are no objects of the given type in existence. However, since this is rarely the case this might not be that big of a deal and instead you might need to deal with more serious cases through the use of soft references. But it is a good practice to avoid this by default where you can as this issue can easily hide below the radar and quickly scale to a few gigs of memory out of nowhere.