Did you try and it didn't work, or did you dismiss it out of hand? It's not a deadline: you create the task_scheduler_init (as an automatic variable, on the stack), you do the work, and you allow the task_scheduler_init to be automatically destroyed.
You may have to adjust your expectations about these callbacks: they are for lifetime or probably career events (to/from RML), but not for taking naps (even if they last until program exit).
The documentation for ~task_scheduler_init() says:
"If no existing thread has any active task_scheduler_init objects, then the internal worker threads are terminated."
If indeed you don't get all exit notifications by the time task_schedule_init destruction has finished (a small reproducer would be useful!), probably the documentation should be adapted, because it may be too difficult to make TBB behave exactly as described here.
I verified from your reproducer (thanks!) that ~task_scheduler_init() does not wait for the worker threads to terminate and be observed to have done so. This did reliably happen shortly afterwards if program exit was slightly delayed (too quickly to notice, but I did not time it). I think that's acceptable... except that the documentation should be more forthcoming (if I can't recall where this may have been mentioned, it's probably not enough notice).