Todos os itens acima provavelmente são verdadeiros. O maior fator que afetou o desempenho no site ASP.NET em que trabalhei foi que tudo relacionado a ele era antigo. A versão do framework .NET, os servidores, a infraestrutura do banco de dados e o próprio código estavam com um envelhecimento muito ruim.
Eu suspeito que muitos sites ASP.NET tendem a ser sites corporativos. Eles não recebem muito amor, pois tendem a funcionar . As pessoas não as reescrevem até que tenham que fazê-lo, o que costuma demorar muito tempo no caminho.
Eu sei que o site com o qual trabalhei que utilizava o ASP.NET obteve uma enorme velocidade apenas ao migrar para a versão mais recente da estrutura, que possuía padrões de JITing e cache de cache muito mais eficientes.
A outra coisa que eu já vi é que muitos sites do ASP.NET não sabem como dimensionar corretamente. Eles não têm o balanceamento de carga adequado configurado, porque projetar seu site para funcionar corretamente com jardins da web não é comum ou está bem documentado na comunidade. Se você não projetou seu site para jardins da Web desde o início, não poderá usar o mecanismo interno de expansão que o IIS possui. O balanceamento de carga de software com o Windows NLB não é muito comum e é complexo de gerenciar. (Isso remete ao fato de que o ASP.NET tende a ser software corporativo e a ser gerenciado pela empresa que administra o site, e não por profissionais de TI que sabem como configurar essas coisas corretamente.)
O balanceamento de carga de hardware com F5s é muito muito caro, mas parece ser o mecanismo mais comum e simples para dimensionar sites ASP.NET em redes corporativas. Eu acho que, entre a multidão de código aberto, a expectativa é que você construa um balanceamento de carga desde o início, usando ferramentas de código aberto disponíveis gratuitamente, que se expandem automaticamente com base no uso. Isso não é comum no mundo do ASP.NET pelo que vi.