A resposta é simples.

SQL Server não materializa CTEs. Ele os alinha, como você pode ver nos planos de execução.

Outros DBMS podem implementá-lo de maneira diferente, um exemplo bem conhecido é o Postgres, que materializa CTEs (essencialmente cria tabelas temporárias para CTEs por trás do capô).

Se a materialização explícita de resultados intermediários em tabelas temporárias explícitas é mais rápida, depende da consulta.

Em consultas complexas, a sobrecarga de gravação e leitura de dados intermediários em tabelas temporárias pode ser compensada por planos de execução mais simples e eficientes que o otimizador é capaz de gerar.

Por outro lado, no Postgres o CTE é uma "cerca de otimização" e o mecanismo não pode empurrar predicados através do limite do CTE.

Às vezes um jeito é melhor, às vezes outro. Uma vez que a complexidade da consulta cresce além de um determinado limite, um otimizador não consegue analisar todas as formas possíveis de processar os dados e precisa decidir algo. Por exemplo, a ordem na qual unir as tabelas. O número de permutações cresce exponencialmente com o número de tabelas para escolher. O Optimizer tem tempo limitado para gerar um plano, portanto, pode ser uma escolha ruim quando todos os CTEs estiverem alinhados. Quando você divide manualmente uma consulta complexa em outras menores e mais simples, você precisa entender o que está fazendo, mas o otimizador tem uma chance melhor de gerar um bom plano para cada consulta simples.