Et je me demande fortement si il est toujours aussi pertinent d’analysé les performances entre langage !
Absolument pas 
Déjà, il faut forcément un peu d’humilité, beaucoup de gens se sont évidemment posés cette question avant nous, et ont écrit sur le sujet. Citer Rob Fletcher (le papa de Spock et Spinnaker si je ne trompe pas) est plutôt sain, sans vouloir verser dans l’argument d’autorité (si Netflix le dit c’est que c’est vrai), il est intéressant de regarder les arguments qu’il avance. Donc tu es sur la bonne piste.
A côté de ça, jouer avec les frameworks de benchmarking, sans avoir la prétention de vouloir prouver quoi que ce soit, est un super exercice pour ta culture perso, je t’encourage vraiment à le faire !
pensez-vous qu’une nette différence peut être visible entre les langages de la JVM ?
Dans certains cas très précis, peut-être. Mais d’une part, il y a de forte chances qu’ils aient déjà été repérés et remontés aux équipes de développement en charge de ces langages (Jetbrains / EPFL dans ton cas) du coup ça vaut la peine de chercher sur leurs github et/ou forums de discussion, d’autre part, il y a très très peu de chance que tu tombes dessus dans la pratique.
"Dans la vraie vie" c’est assez rare (mais ça peut arriver hein !) de tomber sur un "pitfall" du langage : un cas dans lequel il n’est vraiment vraiment pas performant (moins que Java, et moins que les autres langages de la JVM). Si ça arrive, la première étape est de regarder le bytecode généré, reproduire le cas très précisément et le mettre en lumière (cf. JMH mentionné plus haut) et comprendre ce qui se passe fondamentalement avec la JVM (donc aller lire les docs de l’OpenJDK par exemple, qui liste les optimisations "communes" faites par la VM).
Un truc qui m’est arrivé par exemple, c’est me rendre compte que le pattern matching de Scala avait vraiment un impact non-négligeable sur une API que j’avais écrite. J’ai été hyper surpris, mais pour le coup, c’est une fonctionnalité qui n’existe ni en Java ni en Groovy, ni (encore) en Kotlin (les améliorations annoncées récemment sur le when s’en rapprochent beaucoup beaucoup mais c’est pas tout à fait un "pattern matching destructurant" à la Scala). Mais dans mon cas c’était vraiment très net, et plutôt bien documenté, et sur un bout de code qui ne faisait pas grand chose d’autre.
Encore une fois, dans la vraie vie, il y a de grandes grandes chances que les problèmes de performance viennent de la façon dont le code est écrit (anti-patterns, bugs, mauvaises pratiques) plutôt que du langage utilisé. Je dirais que la règle d’or est d’abord de connaître sur le bout des ongles (ou savoir retrouver facilement) toutes les mauvaises pratiques, être extrêmement vigilant sur tout ce qui implique des I/O, et si vraiment le langage semble être en cause, essayer de reproduire le soucis de la façon la plus simple qui soit.
