In response to your edit: I can see how GUI changes would be a problem for RPAs, but that seems solvable. For minor GUI changes, an RPA can theoretically identify where salient features have remained and just re-train on where they were subjected to change. If that approach fails, you can "show" the computer the new GUI and manually identify what changed. If that fails, you can restart training from scratch with the new GUI. That should take less time than training on the old GUI if the new GUI is any good. Maybe that's the best/cleanest approach in most cases and just becomes annoying with complex processes that need a lot of training data.

Keep in mind, though, that RPAs often link together different pieces of software, and if the GUI changes for one of them you'd only have to retrain on that piece. I wouldn't be surprised if enterprise software vendors start optimizing their programs for RPAs so that they don't have to rely on hacky GUI monitoring as much.

The end game is that large, frequently run RPAs will serve as a flag for the organization to develop, find, or outsource an end-to-end program that executes the same process without an RPA. RPAs, then, will always be the scout at the frontier of automatable office work, finding who can be freed from rote drudgery next and serving as a bridge to the best programmatic solution.