Play with any webserver long enough, and you'll realize, they aren't all the same.
On one end, you have light webservers that respond to requests for static content off of a disk, and then send it to the user. thttpd is an extreme example of a webserver like this. Others instead will use apache with hardly any modules installed and, if apache 2.x, a worker MPM can be used that enables each process to serve multiple requests.
Well, that's all fine and dandy, but if you're using PHP or some other language you might find that your web applications aren't thread-safe. Suddenly you have concurrency issues, because you'll have two PHP interpreters running inside of the same process, and this can create enough issues where php recommends against it.
So you equip your apache with mod_php and off you go - but now each request for a small static file bogs down a massive apache process. Which is a bummer, because thttpd or even apache could serve the request with far fewer resources.

So, maybe what you've decided to do is serve images off of one port, and then PHP off of another. Then each web server can have its own port, and you're fine. But, there are all sorts of issues with running webservers on ports other than 80, namely dealing with corporate firewalls and the like. And, ick, think of what that does to your URLs.
With some help from my friend Matt I was able to work out a solution. The nice part is this solution is also very relevant if you're running multiple FreeBSD jails or Linux vservers with one routable IP, and want to have different vservers all be able to serve content to the client via the routable (public) IP's port 80.
The solution: Hostnames. Use a different hostname for each server, and then use a reverse proxy on port 80 that can decide, based on the hostname, what origin server to contact. Then each web server can be run on its own port - either on the routable interface, or a dummy interface, or the loopback device, and they'll still be exposed on port 80 via the reverse proxy.
I used squid. I bound the servers to different dummy IPs on the 10.42.42.1/24 network. If I wanted to use loopback devices, I'd define a bunch of hostnames in my /etc/hosts that resolve to 127.0.0.1, and specify a different port for each.

# i'd like to note that squid's documentation is horrible -matt

# this is to 'accelerate' sites on hillstrom.mydomain.org
visible_hostname hillstrom.mydomain.org

http_port 80 vhost defaultsite=hillstrom.mydomain.org

# this server runs hillstrom.mydomain.org
cache_peer 10.42.42.1 parent 80 0 no-query
cache_peer_domain 10.42.42.1 hillstrom.mydomain.org

# this server runs blargh.mydomain.org
cache_peer 10.42.42.2 parent 80 0 no-query
cache_peer_domain 10.42.42.2 blargh.mydomain.org

hosts_file /etc/hosts

acl all src 0.0.0.0/0.0.0.0
http_access allow all

#stuff below can be tweaked depending on the server used
cache_dir ufs /var/spool/squid 20000 16 256
cache_mem 512 MB
maximum_object_size 256 MB

#logging
logformat common %>a %ui %un [%tl] "%rm %ru HTTP/%rv" %Hs %

Performance wise, if even a small amount of data can be cached by squid, it's actually not that hard to outpace one instance of a loaded (mod_php, prefork) apache. So, it's definitely possible to be smart enough where you can deploy a setup like this and get a performance boost.
Now, as for the actual merits of using thttpd to serve static content... thttpd certainly does a fast job of it, but if you're going to put it behind squid, it shouldn't matter much. Squid can serve up content quickly, too - I did an informal test with a 2390 byte file and found that thttpd could serve it out of the docroot at 2816 fetches/second, squid could serve it out of its cache at 2133 fetches/second, but the loaded apache threads could only serve it out of its docroot at 1550 fetches/second.

I also did a quick sanity check to make sure that squid from cache was faster than squid from thttpd (squid in proxy-only) - and yes, it checked out. For the curious, squid in proxy-only (no caching) with thttpd was ~1653 requests/second, still faster than apache.
What did I learn from this?

1. squid can be used - by regular people and not just squid configuration gods - to reverse proxy for multiple webservers simultaneously, allowing you to effectively present several webservers via one interface and port
2. thttpd is in fact faster than a loaded down prefork apache 2.0 mod_php thread at serving up static content
3. squid isn't as fast as thttpd, but it's nothing to be ashamed of

And the conclusion, for my problem? If we're using our cache properly, then the loaded apache plus squid will maximize hit rates, and it will become far less relevant as to whether the static content is sourced from thttpd or apache. If we have a low hit rate, it might make sense to use thttpd - but for most sites, I can't imagine it would matter.