Sorry about that, the above suggestion indeed does not fix the problem. After a ton of testing, I've figured out what's happening and the fix is equally simple: Call glfwPollEvents() after window destruction.
The whole problem was a side-effect of never calling glfwPollEvents(). The OS X implementation of this method drains an internal
NSAutoreleasePool, which deallocates any reference-counted objects that are no longer active. This includes any destroyed windows/contexts. If you never call glfwPollEvents(), all allocated objects will be stuck in the pool and never released.
Most GLFW programs run an event loop and it's not a bad decision to do memory cleanup once per frame. On the other hand, the documentation of glfwPollEvents() does not mention any memory management side-effects, so never calling it when all you're doing is creating contexts for offscreen rendering/computation feels like a legitimate thing to do. I'll open a GLFW issue for this.