They (nginx, lighttpd) are more difficult to exploit, especially when used to buffer requests to a heavier upstream server like Apache.
EDIT (Clarification):
They (nginx, lighttpd) are more difficult — although not impossible — to exploit, especially when used to buffer requests to a heavier upstream server like Apache.
Specifically, they are typically able to handle many more connections than your application server would be able to (as long as they are properly configured), without the incurring the resource overhead of your application server by bufferring the HTTP request/response.
Nice job editing your comment without saying so (" -- although not impossible --" and your last paragraph).
Anyway, your nginx/lighttpd server is more likely to be exploited and compromised via an actual vulnerability rather than your Apache server via a slowloris-style attack. It's akin to putting a wide receiver in front of your runningbacks...
I updated the original comment w/ the original and updated text. Sorry if you saw this as inappropriate — I had updated it before it was upvoted and thought it only clarified the points, not changed it.
Regardless, many deployments use this same technique for just this reason (to avoid spoonfeeding slower clients responses). How is this any more risky than running Apache up front, barring configuration errors (which could just as easily happen with any other server software)?
EDIT (Clarification):
They (nginx, lighttpd) are more difficult — although not impossible — to exploit, especially when used to buffer requests to a heavier upstream server like Apache.
Specifically, they are typically able to handle many more connections than your application server would be able to (as long as they are properly configured), without the incurring the resource overhead of your application server by bufferring the HTTP request/response.