Some of it would work, but not all.
Begin play executes when the Pawn is spawned (Created). Possession takes place after that. Times for these varies. It’s not reliable.
All pawns are not created at the same time, nor possessed. If they aren’t created and possessed then multicast data isn’t implemented.
Skeletal meshes do not replicate. You can tick replicates, spam multicasts etc until you’re blue in the face, but they will never replicate over the network.
Rep_Notify variables is the way to go here. Rep_notify on a struct is what I use for skeletal mesh changes (cosmetics). I send enums, bools, ints for various struct members.
I pull cosmetic values from a player config (local player) and Pass those values to a Server RPC.
The Server Sets a Rep_Notify Struct (CharacterCosmetics). The Setting of that variable fires the OnRep_CharacterCosmetics function. That struct is now replicated to all connected clients.
The OnRep_CharacterCosmetics function applies the changes directly.
When connected clients receive the struct the OnRep_CharacterCosmetics function fires on their client.
New joins should eventually get an update for the CharacterCosmetics variable from every currently connected player. Yet this depends on the Relevancy & Priority of those players.
Netcull distance is very important in this regard as with NetDormancy settings on the character (Class Defaults → Replication). The default netcull distance is 150m. Outside that distance there’s no relevance unless “Always relevant” is applied to the overlapping actor.
NetDormancy for characters should be set to “AWAKE”.
If all these are set correctly and rep_notified variables are not replicating you then need to execute a Flush.
Before going that route you should debug your onRep functions to print a string as their first order of business.