Thanks for the replies.
From looking at the source of itkProcessObject, you are correct Dženan that the setter just sets the abort flag although it is probably safest to set it from the observer callback to avoid any race conditions. It also seems to get automatically reset by the ProcessObject before it is next run, so there is no need to reset it manually.
The ResetPipeline call is more interesting. It does seem to recurse back up the pipeline towards the original input(s), starting with the output of the process object it is called on. I expect this is the reason for the stack overflow I saw with a circular pipeline. All it seems to do is reset the m_Updating flag unless I am missing something. There is some code in the UpdateOutputData function to handle aborts and exceptions, but it only calls the ResetPipeline function on the current object so anything downstream from it will still think it is updating. For this reason, it is still necessary to call ResetPipeline on the final data object to ensure the whole pipeline is reset before reuse.
I am still seeing some deadlocks when cancelling rapidly, so I will keep digging, although I have not moved on to ITK 5 yet so this may be fixed.