Fondamentalement pas beaucoup, tout dépend de la façon dont ASP.NET et IIS allouent des objets d'attente d'E/S et gèrent la contention et la latence de communication sur le réseau et de transfert de données.
Les threads d'E/S sont mis de côté en tant que tels car ils feront des E/S (comme son nom l'indique) et devront peut-être attendre des "longues" périodes (des centaines de millisecondes). Ils peuvent également être optimisés et utilisés différemment pour tirer parti de la fonctionnalité de port d'achèvement d'E/S dans le noyau Windows. Un thread d'E/S unique peut gérer plusieurs ports d'achèvement pour maintenir le débit.
Windows dispose de nombreuses fonctionnalités pour gérer le blocage des E/S alors que ASP.NET/.NET propose un concept simple de "Thread". ASP.NET peut optimiser pour les E/S en utilisant plus de fonctionnalités de thread non managées dans le système d'exploitation. Vous ne voudriez pas faire cela tout le temps pour chaque thread car vous perdez beaucoup de capacités que .NET vous donne, c'est pourquoi il y a une distinction entre la façon dont les threads sont destinés à être utilisés.
Les threads de travail sont des threads sur lesquels un "travail" régulier ou tout simplement du code/traitement se produit. Il est peu probable que les threads de travail bloquent beaucoup ou attendent quoi que ce soit et seront de courte durée et nécessitent donc une planification plus agressive pour optimiser la puissance de traitement et le débit.
[Modifier]: Je trouve aussi ce lien qui est particulièrement pertinent à cette question: http://blogs.msdn.com/ericeil/archive/2008/06/20/windows-i-o-threads-vs-managed-i-o-threads.aspx