CGI, instant changes. Servlets can be trickier to muck with while the site is live. At development time CGI can be much easier to emulate and verify.

Platform flexibility. CGI is a big win here too. If your boss keeps changing his mind what friggin server software you are going to use, hoo-boy writing servlets is hard. =)

Servlets, deep and fundamental server behavior changes. you can request a servlet decide which format to give the user a graphic in. (aol'ers get gifs, ns+ie<3 get jpg, others get png) You can break the filesystem->url link easily and serve somethings from disk and others from DB, throughout your tree of files, not just up certain branches. Having a tighter link to the server lets you hook things early rather than late why have the server find things on disk you are never going to use, better still let the server find things for you after you tweak where you want it to look.

Servlets, better code reuse, better memory management, better performance under most tasks. In-server caching is much easier.

CGI (deep breath, I can't believe I'm saying this) better security. Messing up a servlet can open gaping holes in your server, massive denial of service holes as well as access holes. You are mucking deep in dark waters and half of what it is doing is a mystery to you.

CGI, no threads, no magic, just run it. =)

---- woof -----

Keep in mind here that I consider mod_perl to be a monster servlet system. And the Java servlets aren't so bad but I HATED EM. =)

HTH

--
$you = new YOU;
honk() if $you->love(perl)