The problem stems from the wrong information passed to the custom workflow-event-type which listens for deletions:

for user objects, the kernel content/removeobject module triggers a workflow with the move_to_trash flag set to true.
It then relies on eZContentObjectTreeNode::removeSubtrees() to actually NOT send the object to the cache, but instead purge it directly.
In theory the information about this could be recovered from the results of the the removeSubtrees() call, and used to appropriately set the values of the parameters passed to the workflow, but this does not happen.

The result is that the staging event which gets generated has the to-trash flag set to true.

This is in the general case not a huge problem, as on the other side of the staging communication there is most likely the same user-account content class, which will disregard the to-trash flag.

It is however a problem for any further extensions which rely on the value of that flag to carry out different actions.