Compare this to my cisco/foundry/other experience where I would delay changes until I was in the office (physically colocated with main routers) or calling people to be onsite for what was 99% of the time an innocuous change. The stress of it led to me deferring changes or just skipping them entirely which led to more issues/stress/etc.
I'm really not sure there is a single software feature which improved my life as much as "commit confirmed"
The problem is that the state in routing tables isn't stored in a single location, it's dynamically built over time. Breaking a single router in the wrong way can break the state, and there's no rollback of that state
It's possible, it depends on what the nature of the change is. If you use super short commit confirmed intervals (commit confirmed 1) then yes you can cause a situation where you revert a "good" commit and cause a second disturbance. You need to intelligently reason about commit confirmed times to consider this when you're making such changes.
And virtual switches aren't the same as physical switches in any case, they have different bugs, different features, different responsiveness.
Ansible/Napalm is a thing in NetOps in some places. Some folks use Eve-ng / GNS3 to spin up virtual networks to test config changes, and it may be possible to do CI/CD changes if you track things in a repo.
Juniper JunOS has auto-rollback if you don't confirm the change after "x" minutes:
* https://www.juniper.net/documentation/us/en/software/junos/c...
So if you did something that causes breakage and disconnection from the router, you (ideally) don't have to do anything but wait it out.