(pasted from my email clippings. I’m on holiday right now, catching up on paperwork!)
The TLDR version is: using AppPoolIdentity as both the App Pool Account and Anonymous user account lets you have multiple isolated anonymous websites on one box.
IIS 7.x (as of Win2008 R2 and Windows 2008 SP2) supports a new Application Pool account type, called an ApplicationPoolIdentity. This low-privileged account can be used to isolate multiple distinct sets of anonymous website content, without requiring the administrator to set up a unique account for each website manually.
And now, the long version!
Before I start: Terminology disambiguation corner (because App Pool Identity is a horribly overloaded term nowadays):
Also, a reminder that process identity is the basic "RevertToSelf" identity for a process, and that thread identity can be different from process identity via impersonation or explicit logon.
So, any or all of the threads in a process might be someone other than the process identity, but if any call RevertToSelf or somehow lose their token, they’ll snap back to acting as the process identity. (Which is the ultra-short version of why you don’t want that being LocalSystem or another privileged account.)
App Pool Account:
The when-not-impersonating/process identity; used to start the app pool and to read web.config files; pretty much needs permissions to everything.
On IUSR vs Application Pool Account as anonymous:
App Pool Account as Anonymous
The alternative is to use an App Pool Account as the Anonymous account (so a thread doesn't bother putting on its IUSR clothes on anonymous requests)
Using the App Pool Account as anonymous is a good idea because it allows you to secure your content at the NTFS level for just COMPUTER\Coke or IIS AppPool\Pepsi, and be assured that Windows file system security will prevent one company's anonymous app from reading (or otherwise affecting) its competitor's anonymous content.
Using the AppPoolIdentity as the App Pool Account in this case is just a simple, no-hassle way of having a common user account on all machines that share the IIS configuration (or at least the name of the app pool), without having to faff about creating or replicating Windows users and worrying about their permission level.
The bit I'm less confident on but still fairly sure I'm right:
When it gets to off-box (eg database) resources, you're out of IIS-land and into app framework (ASP.Net)-land; short version is that if your token isn't delegable (for eg, comes from an NTLM auth), it'll fail to be passed to the next hop, and you'll end up with process identity and any limitations/benefits it incurs.