A lot of the time, the nature of the data and its lifetime makes specialized allocators easy to use. Not infrequently they can actually be more convenient than malloc/free when you have a bunch of allocations (think nodes in a parse tree) with the same lifetime, so their storage can be released as a single operation. For that example, you can get the same usability with a more traditional malloc/free interface using something like hmalloc, but if the parse tree nodes all occupy the same contiguous block, you get it automatically. And of course it's a lot faster to release a single block (if you release the storage back to the OS, the page manager will still have some per-page work for a virtually contiguous block of memory).

Basically, once you have a nailed down system design, it's usually not any significant extra work to use custom allocators. Where it can suck away your productivity is during iterative design and development where you're still figuring out the different kinds of data, what subsystems exist and who owns what when. But in that scenario, garbage collection is even easier than malloc/free, so it's not a mortal sin to use Bochs or just leak memory (heresy!) if you can get away with it--only temporarily, of course, while you figure out the design.