I'm not talking about the PyObject** argument, Victor.
I'm talking about reference counting semantics.  It is a rule that reference counting semantics should be the same over a function call whether that function raised an exception or not.

The this function effectively steals a reference in case of error. The caller owns the reference to the argument (passed by ref) if it succeeds, but if id doesn't, then he doesn't own it anymore.

Reference counting invariance with errors is, as I mentioned, observed with e.g. the 'N' argument to Py_BuildValue(), which is defined to "steal" a reference and does so even if the call fails.  This behaviour is observed by other reference-stealing functions, such as PyTuple_SetItem().  Similarly, functions who don't steal a reference, i.e. take their own, will not change that behaviour if they error.

If you don't want to think about this in terms of reference counting semantics, think about it in terms of the fact that in case of error, most functions leave everything as it was.  PyList_Append(), if it fails, leaves everything as it was.
This function does not.  In case of failure, it will, as a convenience to the caller, release the original object.
It is equivalent to () realloc() freeing its operand if it cannot succeed.

It is precisely these 'unusual' exceptions from established semantics that cause these kind of programming errors.  Originally, this was probably designed as a convenience to the programmer for the handful of places that the function (_PyString_Resize) was used.  But this decision forces every new user of this function (and its descendents) to be acutely aware of its unusual error behaviour.