In a traditional web server the request comes in, some operations are performed to product an output, and the server discards all state. When the next request comes in the server handles it from scratch; authenticating sessions, loading objects in to memory, etc.
In arc, when a link or action is generated the interpreter (I think) the stack is captured an serialized. This, and he closure that the link would execute, is referenced by a unique fnid. When the user clicks on a link the server restores the previous stack and executes the closure as though the response and new request cycle never happened.
This makes it very easy to write web applications; you can concentrate on the exact flow you want rather than creating a bunch of separate-but-linked controllers that have to duplicate a lot of logic. On the down side it does violate the stateless nature of the web. I can't take a link and sharers with you. URLs become meaningless; instead of pointing to a resource they become merely a way to communicate state back to the server.
As a disclaimer: I haven't actually built anything in arc. I have peeked at the HN source code though. I do believe that it does use the traditional-style request handling for some parts where storing the stack causes issues or is unnecessary (e.g. A link from homepage to article uses a traditional stateless URL).