Legal, gostei da sua postagem, até porque provavelmente eu nunca veria isso sem ela.
Primeiro, uma coisa que todo mundo precisa saber que nem todo estudo prova alguma coisa. Na verdade poucos possuem provas, a maioria especulam com alguma fundamentação (alguns nem isso), alguns são bem mal conduzidos, nunca validados e até mesmo é comum serem contestados por outro estudo. Fotra quando apenas o foco é diferente ou o critério não é o mesmo.
Vou dar um exemplo dos estudos que estabelecem o limite de pessoas que o planeta suporta. Os que mais gosto são os que falam em 4 bilhões de pessoas dentro da economia atual (se bem que isso não muda há anos, e não acho que tenha tanta credibilidade assim) e outros que diz que é 1.5 bilhão usando o critério de todas as pessoas terem consumo uniforme nivelado pelos países desenvolvidos. Tem estudo que fala em trilhões de pessoas, o critério deve ser quantas cabem em pé na superfície terrestre.
Estudo sério tem uma forma bastante rígida de ser realizado e publicado. E só passa ter um valor maior quando é publicado por algum veículo científico. Hoje em dia muiutos desses veículos são apenas meios comerciais para dar valor para estudos extremamente fracos, criou-se um mercado para atender os pesquisadores que precisam de uma validação que antes já era corporativista e agora é meramente quuem pode pagar. Tem publicações muito sérias também.
Em gerl nós não acessamos estudos mais sérios, eles chatos, difíceis de entender se não por um pesquisador na área (inclusive muitas validações para publicação são feitas por quem não entende do que está sendo tratado ali).
Claro que podemos ter bons estudos sem toda essa pompa também. Não estou invalidando o estudo que o cara fez, até porque eu precisaria de bastante tempo para isso. Só estou colocando as coisas no lugar para os deslumbrados não teimosos que não tem mais solução entenderem o contexto, até porque tudo depende de contexto.
Dito isso, um JIT sempre tem potencial de conseguir executar algo melhor que um AOT porque ele pode avaliar a execução e fazer otimizações que só fazem sentido para aquele padrão que está ocorrendo isso. Isso não quer dizer que é fácil fazer isso, que compense sempre, e que em alguns casos a análise e regeração do código otmizado pode matar o ganho obtido ou até piorar o desempenho.
Os casos em que o ganho costuma ser frequente porque o padrão se repete é possível ter as mesmas otimizações com AOT se usar PGO (Profile Guided Optimization). E é possível até mais de uma versão de código para padrões diferentes que podem ocorrer, ainda que isso vai engordar seu executável e ter um custo para escolher qual usar. Isso não costuma ser usado porque normalmente não se quer esse preço quando se usa AOT.
Se você conseguisse comparar um AOT e um JIT em condições absolutamente iguais, na esmagadora maioria dos casos o AOT te daria um resultado melhor porque seria comum que as execuções seriam sempre dentro do mesmo padrão. Quando você compara um compilador JIT com um AOT completamente diferente, é o mesmo que comparar um JIT com outros JIT completamente diferente, a chance maior é que a diferença de implementação é que esteja fazendo diferença e não o modelo de compilação.
Por isso estudos precisam ser lidos com cuidado, assim o ovo pode fazer bem ou mal para sua saúde e ambos estão certos. A vida não é o manequismo que cada vez mais as pessoas desejam que exista. Não existem respostas tão absolutas quanto as pessoas querem, por isso que alguns brincam que a senioridade é medida de acordo com a quantidade de "dependes" que ele fala. Se quando você faz o estudo se errar uma vírgula na definição de critério o estudo já pode estar inteiro furado.
Olhando por cima esse estudo mostra uma compração de uma situação encontrada. Não vou questionar se está certo ou errado porque eu teria muito trabalho para fazer isso de forma adequada, correria o risco de errar também, mas quero ressaltar que ele mostra só o que está aí, qualquer especulação que o JITando já consegue ser melhor que Ahead Of Time não pode ser feita.
Por isso que eu semrpe falo que linguagem não possui velocidade. No máximo a implmentação possui. Claro que algumas características colocadas na sua específicação podem facilitar ou dificultar ter perfroamnce, mas é possível ter mecanismos que melhorem o resultado ou que piore muito sem necessidade. E você pode fazer um teste que uma implementação de uma linguagem ganha de outra implmentação da mesma linguagem ou de outra linguagem e uma mudança mínima no código pode dar o resultado contrário. Mais ainda, em uma nova versão da implementação o resultado pode ser outro.
Eu acho ótimo que o JITters estejam melhorando, até porque ele sempre vão puxar o AOT+PGO para cima junto e todos saem ganhando.
Um dos grandes problemas dos compuladores Just In Time é que ele engordam o executável e gastam mais energia para executar, nem sempre você quer isso. Mas ele pode trazer benefícios que enxugam o código total e economizar energia ou outros recursos.
Em tempos de uso mobile, IoT, serverless e outras coisas pagas pelo uso, e até a IA, escolher o melhor modo de compilação, e a tecnologia mais adequada, sempre que possível, é outra skill que o bom programador deve ter.
Em se tratando de linguagens diferentes pode ser que para obter o melhor resultado precise fazer um código diferenet na outra linguagem. Quase sempre o código já é um pouco difeente, então a comparação não é exatamente banans com bananas, nem mesmo banana prata com banana prata. O Clang pode ser assim, mas o GCC ou VSC pode ser de outro jeito, ou ainda a próxima versão do Clang pode dar um resultado diferente, até mesmo pode ser uma versão mais antiga que dava e hoje não dá mais, embora seja menos provável.
Equivalência de código pode ser ótmo para comparar algo, mas pode ser justamente o que destrói o resultado.
Me lembro de um caso de muitos anos atrás que um funcionário da Microsoft fez uma versão de um software de um dos maiores figurões da empresa, bem conhecido em que ele portou para C# o que era original em C++. Na época o JITter do .NET era ruim. E o código em C# ficou mais rápido. O "japonês" figurão da Microsoft começou mexer no dele em C++, introduziu bugs no processo e teve um trabalhaão para chegar em uma versão (a sexta) que batesse o C# de forma definitiva. Vou contar essa história em detalhes no meu canal que estreará em breve.
É quase certo que sempre você conseguirá obter um resultado melhor em C++ do que em Java ou C#, aina mais no estado que eles estão hoje que ainda tem muito potencial para melhor (até C++ ainda tem) nas otimizações. Mas o trabalho será cada vez maior para conseguir.
Você já viu como a STL é implementadas nas bibliotecas dos diversos compiladores? Você não consegue entender nada do código, é algo de uma complexidade absurda. Por que alguém faria isso? Para obter a melhor performance. Vale o esforço porque o mundo todo se beneficiará dele.
Para te ajudar bastante teria que fazer uma análise microscópica, analisar o código final gerado que realmente executa para descobrir o que aconteceu. Mas já posso dizer que a compração ficaria mais justa se fizer um PGO (coisa que nunca fiz em C++).
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).