If callbacks are pending at this point, then they've been triggered and are just waiting for thread space to be executed.
The purpose of the call here is exactly that - to cancel any pending callbacks that are about to be executed.
On the other hand, this isn't going to stop callbacks that are already in process.
Yes. According to the MS documentation for SetThreadpoolTimer(): _"In some cases, callback functions might run after an application closes the threadpool timer."_ (Remarks section) https://learn.microsoft.com/en-us/windows/win32/api/threadpoolapiset/nf-thre...
Although they seem to imply that this includes also the queued callbacks, not just those in the execute phase: (pftDueTime parameter) _"If this parameter is NULL, the timer object will cease to queue new callbacks (but callbacks already queued will still occur)."_
And also in the Remarks section of CloseThreadpoolTimer(): _"The timer object is freed immediately if there are no outstanding callbacks; otherwise, the timer object is freed asynchronously after the outstanding callback functions complete."_ https://learn.microsoft.com/en-us/windows/win32/api/threadpoolapiset/nf-thre...
Since the tp_object_cancel() removes pending callbacks, it can probably be removed. It won't make much of a difference though, and I think it makes more sense to cancel the pending callbacks there.