Other than needing to fork for every request, this should be really fast because it uses the efficient sendfile() mechanism in the kernel to handle returning the file and most importantly only implements a bare minimum of support for the protocol. nginx is almost certainly going to be slower because it has to worry about different types of requests, different protocols, IPv4 vs. V6 sockets, CGI, etc...
It's easy to make something fast when you only implement a very small number of features.
IIRC, Nginx can use sendfile too, it's just not there by default because the transfer happens entirely in kernel space and hence you cannot apply filters like gzip on the response (correct me if I'm wrong).
Yes, that's what my sense is: it would, within its very limited domain, beat nginx and co. fairly easily.. its interesting because this sort of thing could be made to be modular and thus feature extendable without the overhead if done in a smart enough fashion - many webservices today are sufficiently specialized that they only use a fraction of the features that modern webservers include.
It's easy to make something fast when you only implement a very small number of features.