Hm I'm still not sure I understand what you mean by "sets up and tears down the entire main loop". Even in normal cocoa applications every keystroke or input event causes an event to be dispatched from WindowServer to the application which gets handled by the runloop. The expectation of course is that you never do any blocking work on this runloop. nextEventMatchingMask doesn't have to block, you can have it return if there are no events that need to be processed so it can integrate with your own runloop (of course bypassing [NSApplication run] and implementing the runloop yourself this way is discouraged, but I don't think it's forbidden)
The model of "slurp some events from a queue-like thing, throw some drawing at another queue-like thing, then wait for another event" is precisely what [NSApplication run] already implements. Per Apple
>A Cocoa application is event driven: It fetches an event from the queue, dispatches it to an appropriate object, and, after the event is handled, fetches the next event. With some exceptions (such as modal event loops) an application continues in this pattern until the user quits it.
Yeah I can't see it tearing down the message pipe, that would exit the app.
But what it is doing is first posting a message that will call `[NSApp stop]` then calling `[NSApp run]`. Which is odd, because `[NSApp nextEvent]` exists, but even if that doesn't work it's not the way I'd do it. However I'm sure there are very good reasons to do it this way when you know the emacs source.
With an old and conservative project like Emacs, the reason could just as likely be that it was done that way for the NEXTSTEP port in the early 90s and that nobody revisited it since then. Oftentimes the reason is just legacy, limited manpower and "don't fix what ain't broken".