Yes if you allocate all 100000 objects nearly once and then free them nearly once, and then allocate again etc, keeping them in a pool in between for faster reallocation seems useful but...
... but if your objects can be allocated and deallocated by different threads, and you want to avoid excessive syncronization, you would need a thread-specific object pools,..
... and then you find out that TBB does not provide enough information to you to implement thread-specific pools and you at least need a cross-platform abstraction over thread-local storage,..
... and then you find out your objects can migrate between threads and be deallocated in a different thread than they were allocated in, and you would need to provide some mechanism to compensate such migration and prevent object hoarding unused on consumer pools, and you would need some syncronization for that...
...and if the initial design in your mind is a contiguous array of objects that transfers into a singly-linked FIFO list as objects get allocated and freed,..
then I suggest you to re-think now :) because the scalable allocator did all that already, with relatively little additional overhead, in many cases in a non-blocking manner.
In fact, the TBB task scheduler uses internal pools of free task objects. But we do that in purpose, e.g. for sake of customers who don't want to distribute yet another DLL (I mean tbbmalloc.dll) with their product and TBB ends up using vanilla malloc() which might be slow with multiple threads. And we have fought object hoarding (often perceived as leaking memory) enough already for me to warn you :)