Fundamentalmente no mucho, se trata de cómo ASP.NET e IIS asignan objetos de espera de E/S y gestionan la contención y la latencia de la comunicación a través de la red y la transferencia de datos.
Los subprocesos de E/S se reservan como tales porque van a hacer E/S (como su nombre lo indica) y pueden tener que esperar durante períodos de tiempo "largos" (cientos de milisegundos). También se pueden optimizar y usar de manera diferente para aprovechar la funcionalidad del puerto de finalización de E/S en el kernel de Windows. Una única cadena de E/S puede estar administrando múltiples puertos de terminación para mantener el rendimiento.
Windows tiene muchas capacidades para manejar el bloqueo de E/S, mientras que ASP.NET/.NET tiene un concepto simple de "Subproceso". ASP.NET puede optimizar para E/S mediante el uso de más de las capacidades de subprocesamiento no administradas en el sistema operativo. No querrá hacer esto todo el tiempo para cada hilo, ya que pierde muchas de las capacidades que .NET le ofrece, razón por la cual existe una distinción entre la forma en que los hilos están destinados a ser utilizados.
Los subprocesos de trabajo son subprocesos sobre los cuales ocurre el "trabajo" regular o simplemente el código/procesamiento. Es improbable que los hilos de trabajo bloqueen mucho o esperen nada y serán de ejecución corta y, por lo tanto, requieren una programación más agresiva para maximizar la potencia de procesamiento y el rendimiento.
[Editar]: También encontré este enlace que es particularmente relevante para esta pregunta: http://blogs.msdn.com/ericeil/archive/2008/06/20/windows-i-o-threads-vs-managed-i-o-threads.aspx