Right, 60s is above the Openroadm whitepaper recommendation, I remember it is a security we put for implementations deviant from the specifications and I don't think the operations can be performed simultaneously.
60s and 10 min look very inefficient in IP or Ethernet devices but this is not unusual in WDM optical domain where amplifiers and WSS convergence times are much longer.
I let Olivier and Dhruv correct/confirm/complete this answer.

If the connection and power setup are launched in parallel through a multi-thread in A to Z and Z to A direction, the power setup will be made sequentially across the different nodes of the path. We kept 60 s to begin with first OpenROADM implementations, but Release 2.2 will allow us to reduce this timer back to 12s.

Not a bug but a tolerance slot for older implementations (that are still often found today).
The timer can be adjusted safely o newer implementations if needed.

Understood. The thing I'm still wondering about is whether it has to be a fixed timer. What it the node instead explicitly reported back to the controller when the power level target has been achieved? That would allow handling both slower and faster node implementations without modification of the controller code. For reference, the OpenROADM MSA spec has an example for setting MW-MW power level (see "Local Control" sheet) where the final two steps are:

3. The node must report the actual ingress and egress channel powers and total powers measured, through the NETCONF interface
4. the controller can optionally change the control mode to "Gain" which will lock in the internal gain settings which was last used to control the power. This decouples this controller from all other cascaded controllers

I agree it can be implemented this way. It would mean that we have either to deal with a netconf notification or to create a control loop to poll the netconf device configuration. Both with a timeout security. I'll raise the point for our next sprint.