On casual inspection, it looks like it keeps trying to clear the table and reinstall the same table entry. A decent guess is that this is in response to seeing the error... the controller is possibly pushing a table entry followed by a barrier request so that if it sees the barrier reply before seeing an error, it knows the table update has been successful (otherwise it'd have seen an error from the flow-mod before the barrier reply). The fact that the barrier itself causes an error throws a wrench into this. But this logic is inside Pyretic (or SDX), not POX itself. When we've had to make POX components work with HP switches, we've actually specifically identified errors caused by barrier requests and treated them the same as the barrier reply would have been (the POX connection logic does this, for example, IIRC).
Incidentally, the reason the assertion you mention tripped is because of an unrelated way in which the HP switches are questionable. It should never really have been an assertion, since the problem is with the switch and not POX, but this predated POX's libopenflow having logging infrastructure so there wasn't another good option at the time. I've corrected this in my local branch so that it now properly issues a warning and continues. This should eventually get pushed to the eel branch of POX.