I just fixed an odd 403.14 server error on my Server 2008 VM, and what was the problem? My application was set to the "DefaultAppPool" app pool. The cause? "DefaultAppPool" doesn't exist, and yet my web site is somehow set to run on "DefaultAppPool". "DefaultAppPool" didn't event exist at the time I created the web application in IIS, much less now. By all means this should not have been a problem--IIS should set newly provisioned web sites to an existing, non-imaginary app pool--yet it was a problem.

So, advice: don't delete the default app pool, even in the new hotness that is IIS 7 and Windows Server 2008. You certainly can do so--I'm not saying it's impossible to get along without the default app pool; I'm just saying that you'll have surprises. And not the "congratulations, it's the prize patrol" type surprises, more like the "congratulations, your vehicle has been towed!" surprises.

You don't have to take my word for it--instead listen to Joel Oleson (talking about IIS6), and I quote:

Default Application pool

Just leave it alone, don't use it, and occasionally make sure nothing is using it.  Do NOT delete it.  Why... Cause IIS doesn't like it when it doesn't exist.  You'll find IIS gets mad if this gets deleted.  Even if you plan to never use it, just leave it alone.  Don't even rename it.  You can put something funny in the description field to remind you, but as was the unspoken best practice in the IIS 4 and IIS 5 days with the default web site.  Only newbies use it, the more experienced web admins create new web apps and stop or deleted it.  Now I'm saying though you may want to delete it. Don't.