When you say '...to recover' I assume you mean that during this time there is no forwarding of your user-data in your entire network, not just the fact there is a delay in bringing up the uplinks to the newly connected root-switch.
Well, I guess that is by design.
Essentially, all switches start a complete discovery cycle because this new switch is suddenly seen and it claims to be the root... so they all start learning this new topology fist, and forget about all the data that needs to be forwarded.
I can't think of a proper way to prevent this.
What you could do if you really need to prevent this, and have the switch online asap...
While your original root is down, configure the switch that is root at this time to have a priority that is enough to force the original root NOT to become root again when you switch it on (that's why I always prefer to configure 'prio 1' on root bridges instead of 'prio 0'). With a bit of luck (try it in a lab) this can be done without impact. That way, you will probably prevent this 'shut-up-and-listen' downtime when booting your original root.
You probably want to promote your original root to become root again, but you can postpone this to a maintenance-window, without loosing redundancy in the mean time.
But to be honest... I would not recommend this procedure.