Sure, the idea is that you can have several allocators around for different purposes. One allocator per http handler that reserves enough memory and resets the pointer between request makes the idea more feasible than insisting on the centralized general purpose perspective.

Except if the program needs to run for a non trivial duration or you need many instances of it at the same time/run at the same time as other processes.

Still you have obstacks where free is a no op - here you allocate off the stack (assuming that you dont need to store pointers after you are done). Ngnix and apache allocate a chunk of memory per connection and free it all when the connection is finished - but this results in high memory fragmentation, also this is not so good if connections take a long time.

Somebody out there is doing this in production. I guarantee it.

Why wouldn't they? If it turns out to be a good solution for the problem they're trying to solve? There's nothing wrong with coming up with your own solutions, that's why we got brains instead of answering machines.

It is a problem if it's not properly documented. This system will probably outlast their time at that company, so the next poor shmuck is left to figure out what that program is doing.

Agreed, but that's an if; there's no reason to assume anything. And the next scmuck also doesn't need to spend most his time struggling to find a combination of dependencies that still kind of work. There are advantages to owning your code.

There was a console game (I want to say Sega CD? CD32? or Atari Jaguar?) that reset whole system between level loads because it was cheaper than freeing memory.

Or add a simple GC to that, if you need to recycle memory during longer runs, and your stack is too small to hold most allocs.

Given the evaluation criteria, this sounds like a winner to me.