It's only unparalleled if you've never heard of the C99 'restrict' keyword. The major reason is like every other legacy system still in wide use, inertia. LAPACK alone will guarantee Fortan's life for decades to come.
If only every compiler vendor supported C99 (coughMicrosoft), perhaps C99 would be a usable alternative.
And, inertia isn't the only reason for Fortran remaining popular. Put simply: if you tell a mech.eng./physicist/whatever to write code in Fortran, whatever is produced will likely be fast and relatively readable. Do the same with C/C++, and it will be significantly slower and a horrible mess. Templates-all-the-way-down type of stuff.
Sure, a software engineer could write a C/C++ version that was elegant and as fast/faster than the Fortran code. But scientists don't have the money to hire software engineers. You're lucky if these projects are even under version control.
More importantly, if your simulation software is made by a computer engineer without the direction of a scientist you might just end up with a really slow and biased random number generator.
I've said it before - leveraging "restrict" is far from trivial.
In practice, what you do is look at the assembly of your inner loops, scratch your head, and try putting "restrict" in various places that seem like they'd make sense, and then look at the assembly of your inner loop. Which requires building a mental model of what the assembly of your inner loops ought to look like, and then actually looking at it, and then running it to see if your idea of what the assembly out to look like was actually a good one.
If your expertise is in numerical methods first and assembly-level optimization second (or, like, nth), Fortran can save you a lot of ballache.
