It's probably the most popular threading model, because it's reasonably simple to implement, and is the fastest model when the maximum number of ``simultaneous'' (at the time scale of the service completion) requests is in the order of a few tens. The server sits in a loop accepting forthcoming connections, and as soon as they arrive it spawns a thread that is responsible for handling the client for all the duration of the connection. Using a separate thread for each client has the advantage of reducing complexity, because each code path needs to perform only a single operation: the main thread accepts connection, and the child threads service them.
The downside is that this model doesn't scale well with the number of clients, for two reasons: because of the demands of each service thread on system resources, and because the of time the system spends context-switching (or, even worse, process-switching) among threads. With current technologies, this last term significantly impacts the server's performance when there are more then a few tens of threads running. With increasing number of connections, both terms reduce the rate at which each client can be serviced up to a point when accepting new connections becomes impractical.