Parece um daqueles casos em que simulação (ou acesso ao código-fonte ...> suspiro <) provavelmente será a única maneira de ver qual é o comportamento com algum grau de confiança.
A documentação para a entrada do log de eventos para reciclagem de cota de CPU fala sobre reciclagem da seguinte maneira:
Por padrão, a reciclagem do pool de aplicativos é sobreposta, o que significa que o processo do operador que deve ser desligado é mantido em execução até depois que um novo processo do operador é iniciado. Depois que um novo processo de trabalho é iniciado, novas solicitações são passadas para ele. O processo de trabalho antigo é encerrado após o término do processamento de solicitações existentes ou após um tempo limite configurado, o que ocorrer primeiro. Essa forma de reciclagem garante um serviço ininterrupto aos clientes. No entanto, se um aplicativo no pool de aplicativos não puder executar mais de uma instância por vez, a rotação sobreposta poderá ser desativada.
Parece-me que, por definição, encerrar um processo de trabalho por causa do consumo excessivo de CPU significa que as solicitações pendentes não podem ser concluídas (pois estão esgotando a cota de CPU).
Para falar com sua principal preocupação: não estou vendo nada que me leve a acreditar que um novo processo de trabalho não seria gerado automaticamente. A declaração no link Stack Overflow me faz questionar se o algoritmo usado pelo IIS pode, de fato, vincular a reciclagem à resolução do timer usado para medir a exaustão da cota de CPU. A melhor maneira que eu sei para determinar isso seria escrever um componente do lado do servidor que desperdice a CPU, implantá-lo em um ambiente de teste e ver como seu comportamento de reciclagem atua. Um componente simples que fica em loop apertado por alguns segundos e depois retorna uma string conhecida, combinada com um cliente executando um equipamento de teste com algo como um conjunto de processos "wget" paralelos, pode ser suficiente.
Dados os comentários da outra resposta, eu fiz meu próprio teste, que replicarei aqui.
Nos meus testes, limitar um pool de aplicativos (v4.0 Integrated) a um pequeno limite de CPU (0,01%) e um pequeno intervalo (1 minuto) com a ação KillW3WP ativada, ultrapassar esse limite mata o w3wp interrompendo o pool de aplicativos .
Depois que o limite do intervalo é atingido, o pool de aplicativos é reiniciado automaticamente .
Alterar a ação para Nenhuma ação não altera o processo w3wp.
Nos dois casos, um evento de sistema 5025 é registrado.
fonte