Não é necessariamente o hotspot, ainda mais pra poucas requisições. Tem outras coisas que podem ter contribuído para este resultado.

Quando a JVM começa a executar, tem uma série de coisas que ela precisa fazer para iniciar. Por exemplo, tem várias estruturas internas que ela precisa inicializar, o classloader tem que carregar várias classes, etc. Por isso até hoje Java é conhecida por ter um startup mais lento que as outras linguagens.

Isso já explicaria a primeira requisição ser mais lenta, porque apesar de muitas classes nativas já terem sido carregadas, várias outras (incluindo as classes envolvidas no teste) só o são sob demanda. Por isso que muitas libs de benchmarking costumam ter uma fase de warmup para que esta demora inicial não interfira nos resultados.

Aliás, fica a dica de testar usando alguma dessas libs, em vez de comparar os timestamps. Para testes simples eu uso o JMH, mas existem várias outras (busque por "java benchmark tools" e escolha a sua).

Também pode ser que o Garbage Collector tenha rodado no meio do teste, interferindo no tempo de resposta. Apesar dos algoritmos de GC terem melhorado, o impacto deste nunca é zero. Pra isso, precisaria analisar com mais detalhes (pesquise por "ferramentas de profiling").

E vale notar que até aqui, não temos nada de hotspot.

O mecanismo de hotspot (que é parte de algumas JVM's, entenda melhor aqui) é o que faz com que um código que tenha executado "muitas vezes" seja otimizado. Neste caso o JIT (just in time compiler) entra em ação e re-compila aquele trecho para código de máquina (na verdade é um pouco mais complicado que isso, veja aqui).

Mas este mecanismo só entra em ação depois de muitas execuções. O valor exato é difícil de determinar, conforme explicado aqui, mas garanto que somente 5 execuções não é nem perto do suficiente para ativar o hotspot.