Even if the router does get a new IP, we won't know they did anything. Changing the endpoint on the interface just causes the tunnelserver to change the endpoint. Tunnels only go down on this side when they're deleted.
Obviously I don't know the implementation details of the service. I don't even know which underlying routing platform it is implemented on. (Differences between the behaviour of the different tunnel servers have given me the impression that they are not all the same, but maybe different versions of one routing platform.)
Most likely the tunnel server and the webservice can get out of sync. And by out of sync I mean what is configured on the tunnel server is not what you'd expect from looking at the setting in the webservice. Getting out of sync like that could easily be the consequence of some rare communication problem not being handled correctly. A well designed system would somehow correct that, and one way it could be corrected is by deleting and recreating the tunnel.
Of course what I was imagining is not the only sensible way to design such a thing. I do think deleting and recreating the tunnel would be more reliable in certain corner cases, but it might not be necessary.