Why would I write custom allocators for STL containers when I could just overwrite new and delete?

If you want to replace the global allocator, including in every library you are using, you don't have to use std::allocator.

std allocators let you do things like create temporary allocation pools. Suppose you have some data structures you can guarantee will not outlive a certain scope, and you know that (whatever is allocated) 90%+ will remain allocated to the end of the scope.

A relatively simple std allocator could hand outmemory, never recycle it, and clean it up at the end of the scope much faster than any global new or delete operator could.

Whenever you have special knowledge of the contents and lifetime patterns of a container, you could hand-tune an allocator for that specific container. The standard allocator cannot. Sometimes when you are willing to make compromises that the std containers are not, you can patch their behavior with a custom allocator.

std::deque cannot efficiently use a stack allocator, because it cannot presume you'll mainly use it as a stack. You might use it mainly a queue. A stack allocator when you use it mainly as a queue would be a disaster; but if you used it 90%+ as a stack, a stack allocator could be much faster at the cost of modest memory overhead (and if 99%+, a stack allocator that handles the exceptional case and cleans up the non-stack based operations).

Finally, allocators can permit you to distinguish between kinds of containers. You might want the memory for your document (persistent) state to be allocated in one region of memory, and your "scratch" non-persistent data to be allocated elsewhere.

And yes, using a std allocator is something you should consider not doing. Optimization is fungible, and tweaking low level memory allocation is something you can work on after you have made the rest of the system more efficient and functional. Only when you have something that works, isn't fast enough, and you have identified new/delete as a fundamental bottle neck you can't design around should you say "ok, time to replace allocation!"

Use Case: Security Software needs to shred memory on delete, 'cause it cannot afford to let sensitive data remain somewhere in the physical RAM, optionally accessible by later instantiated processes. The delete operators of standard run-times won't do this expensive operation. Overwriting the heap operators might lead to linker problems with libraries depending on the runtime versions of those.

Answering the two questions in-order:

Should I write custom allocator_traits to interface my allocators for the various STL containers?

Yes, for easy manipulations. Pretty soon in the implementation, situations such as controlling memory overlaps would arise. For example, while stress-testing the implementation at full capacity of individual allocators and figuring out an algorithm for re-allocation. In this regard, you would need to specialize the allocator_traits class for the allocators rather than implement its member types from scratch using new and delete operators.

The reason allocator_traits is used is because it facilitates easy handling of certain rules that need to be respected. Such rules occur all across memory management. [Refer here for three such rules during allocator construction.]

What tangible benefit I would gain from having separate allocators for STL containers?

Absolute control of how the master allocator assigns, re-assigns, copies, moves, and destructs memory (with added controls over quantifying/enhancing performance). Pretty cool, isn't it! If the default std allocator is used, you would loose this control and rely on a (albeit very good) default implementation of memory management.