Few projects are completely new projects. I'm not sure it's specific to scientific computing, but at least in this field, you tend to build your applications based on existing (scientific) models, perhaps produced by other groups/people. You will always have to deal with some amount of legacy code, whether you want it or not.
Fortran is what a lot of scientists have been taught with and what a lot of the libraries they need are implemented in. A number of them might not be computer scientists or IT people, more computational scientists. Their primary goal is rarely computing, it's their science first.
While a large number of programmers would have a tendency to learn a new programming language or framework whenever they get a chance (including during their spare time), most scientists would use that time exploring new ideas regarding their science.
A domain expert who's trained in Fortran (or any language) and surrounded by people who are in a similar situation will have no incentive to move away from it.
It's not just that now other languages can be as good as Fortran in terms of performance, they need to be much better: there needs to be a good reason to move away from what you have and know.
It's also a "vicious" circle to a degree. I've always found comparisons between Java and Fortran a bit difficult, simply because a number of Java scientific applications are not programmed in a Java way. Some of the Java Grande benchmark applications look clearly like Fortran programs turned into C programs, copied/pasted/tweaked into Java programs (in a method, passing the length of the array as an extra parameter next to the array itself gives a clue, if I remember well). Because of this, Java (for example) hasn't got a great reputation in the scientific community, even though its performance is getting better. A consequence of that is that there is little overlap between HPC experts and Java experts, for example. Even from the hardware vendors or libraries implementors, little demand from users leads to little support offered, which in turns deters users who would potentially be interested in moving to other languages.
Note that this doesn't preclude the same (or other) scientists from using other languages for other purposes (e.g. workflow management, data management, quicker modeling with Matlab, Numpy, ...).