IUSR e IWAM se remontan a los primeros días de IIS, cuando se instalaba por separado (no como un componente del sistema operativo). Por defecto, si un sitio web permite la autenticación anónima, se utiliza la cuenta IUSR con respecto a los permisos en el SO. Esto puede cambiarse respecto al valor por defecto. Hay algunas recomendaciones de seguridad para al menos cambiar el nombre de la cuenta, para que no sea una cuenta "conocida", al igual que hay una recomendación para cambiar el nombre de la cuenta de administrador en un servidor. Puedes aprender más sobre IUSR y autenticación en MSDN .
IWAM fue diseñado para cualquier aplicación fuera de proceso y sólo se utiliza en IIS 6.0 cuando está en modo de aislamiento de IIS 5.0. Normalmente se ve con objetos COM/DCOM.
Con respecto a las identidades de los grupos de aplicaciones, el valor predeterminado es ejecutarse como Servicio de Red. No debe ejecutarse como Sistema Local porque esa cuenta tiene derechos superiores a los de un administrador. Así que eso te deja básicamente a Servicio de Red, Servicio Local, o una cuenta local/dominio diferente a esas dos.
En cuanto a lo que hay que hacer, depende. Una ventaja de dejarlo como Servicio de Red es que se trata de una cuenta con privilegios limitados en el servidor. Sin embargo, cuando accede a los recursos a través de la red, aparece como Dominio \ComputerName $, lo que significa que puede asignar permisos que permitan a la cuenta del Servicio de Red acceder a recursos como SQL Server que se ejecuta en un cuadro diferente. Además, como aparece como la cuenta del equipo, si habilita la autenticación Kerberos, el SPN ya está en su lugar si está accediendo al sitio web por el nombre del servidor.
Un caso en el que consideraría cambiar el grupo de aplicaciones a una cuenta de dominio de Windows en particular si quiere que una cuenta en particular acceda a los recursos en red, como una cuenta de servicio que acceda a SQL Server para una aplicación basada en la web. Hay otras opciones dentro de ASP.NET para hacer esto sin cambiar la identidad del grupo de aplicaciones, así que esto ya no es estrictamente necesario. Otra razón para considerar el uso de una cuenta de usuario de dominio es si se hace la autenticación Kerberos y se tienen varios servidores web que dan servicio a una aplicación web. Un buen ejemplo es si tienes dos o más servidores web sirviendo a SQL Server Reporting Services. El front-end probablemente sería una url genérica como reports.mydomain.com o reporting.mydomain.com. En ese caso, el SPN sólo puede aplicarse a una cuenta dentro de AD. Si tiene los grupos de aplicaciones que se ejecutan bajo el Servicio de Red en cada servidor, eso no funcionará, porque cuando salen de los servidores, aparecen como Dominio \ComputerName $, lo que significa que tendrías tantas cuentas como servidores sirvieran la aplicación. La solución es crear una cuenta de dominio, establecer la identidad del grupo de aplicaciones en todos los servidores con la misma cuenta de usuario de dominio y crear un SPN, permitiendo así la autenticación Kerberos. En el caso de una aplicación como SSRS, en la que se desea pasar las credenciales de usuario al servidor de la base de datos back-end, entonces la autenticación Kerberos es una necesidad porque entonces vas a tener que configurar la delegación Kerberos.
Sé que es mucho para asimilar, pero la respuesta corta es que, excepto para el Sistema Local, depende.
