The issue is that traditional web servers use a thread per socket approach to handling concurrent users which is not always optimal for comet/long polling techniques. (Newer versions of IIS have a way to plug in your own connection handlers however, which I will get too below.)
For the traditional web servers, more often the goal is to get a connection, serve the user up something as quick as possible, and move to the next connection. If a connection is lingering for a long time, its because its probably doing something intensive, like a big download or huge query but overall its actively using the CPU so the threaded model works pretty well.
In comet (long polling), normally you are connecting to a web server where you just wait for an event to occur, and more often than not. This promotes more concurrent connections. Also chacnes are that many of these users are waiting on the same events to occur across the board.
Allocating a thread then for a user to primarily just spin and wait is not a very optimal model for this type of thing. A better model is a event loop based web server that does everything in an asynchronous kind of fashion, and where dispatching off an event to multiple users doesn't involve a costly context switch for each client. This what Node.js is built on (using libevent as its core), as well as Ruby Eventmachine, Twisted Python, Friendfeed's Tornado, Jetty, and the C# based Manos server.
That is why there it's often more advantageous to have comet done on its own process custom a custom server since traditional web servers like Apache and older versions of IIS do not function in a matter that is efficient for Comet's needs.
Standard ASP.NET apps are little bit screwed because thread pool in .NET is limited to 25 general threads and 25 IO threads (and http connections take an IO thread). You may be effectively limited to be slightly less than that in reality because the thread pool is shared with all the other things in .NET. You can bump the thread pool up though with a configuration setting however, but performance has a tendency to decay exponentially the more threads you throw in. You could in theory bump this number up if you can guarantee you won't grow too much, and then possibly just use standard thread monitors in .NET to build your own comet event dispatching thing.
However .NET apps running newer versions of IIS do have a ray of hope though. You can create a custom IAsyncHttpHandler. There are some great guides online for you read up on how this works. With that you can build up your own connection pool and serve your clients more efficiently. It's not a perfect solution and you have to build out lot of plumbing on your own. WebSync is a commercial product that wraps this interface for you and gives you some high level framework pieces you can work with however.