It is not good for performance to do a double RPC for everything, in my limited experience.
Wherever I can get away with it, I just do a client-to-server RPC to change the replicated variable or spawn the replicated Actor on the Server, and then let the Server decide when and if to replicate.
For things that need to happen right now no matter what, then I use the double RPC.
For things that need to happen no matter what but can wait until the next replication update, I use client-to-server RPC to set a RepNotify variable and let the clients handle the repnotify function it fires.
My worst performance on network has happened when flooding it with repnotifies every tick just to let other clients see a change in my tank’s engine glow brightness. I changed from that to just tracking the changes clientside, sending an unreliable client-to-server RPC every 0.25 seconds, and letting the server decide when and if it thinks clients need to see the change, and it still looks great, and is way less laggy! I can do it on that feature because it’s not game-play critical.
For things like explosions when a tank dies, I use a double RPC to make sure everyone knows that it happened at that moment, and they all spawn the explosion on their own client side. I am thinking maybe I should change it to spawn a replicated particle emitter actor instead though, and make it a single RPC. There is a noticeable stutter when I do it the first way.
Optimization is going to be about figuring out which of these 3 cases your client-side changes fall into (those that other clients need to see happen).