Later in the README, the author suggests to put a reverse cache in front of the server, which seems to me far more elaborate than avoiding to put a bunch of files on a server.
The cache server definitely adds complexity and more so than a static site. However the complexity is setup and done once on initial server setup. On-going, the multi-process of a site generator adds up. Granted its one small step which as you say most already have scripted tasks.
Answering the first comment, the use case was something to play with for my personal site which I wanted to share if others found useful.
It appears, before the rebuild, you had a feed @ http://mkaz.com/rss.xml — which is gone. I guess the Lanyon web server doesn’t generate atom or RSS feeds out-of-the-box?
That’d be a pity, while a Web based on Markdown+Git+WebSocket (or something alike) still is a long shot…
Considering that most programming languages ship with a good webserver for serving static content already, I don't see how it makes the product that much more complex. Coming from another angle: now I have a webserver that renders markdown ;).
It has a built-in server with watch mode and regenerates the entire site upon file changes. It’s blazingly fast (as long as you don’t use the syntax-highlighting plugin which calles out to pygments and is rather slow).
Aside: I have been using highlight.js[1] instead of pygments lately.