https://en.wikipedia.org/wiki/Row-_and_column-major_order
In short, people solving numerical problems want to write like M[i,j] where i is iterated through on the innermost loop and j is iterated through on the outermost loop... and if the language works in sympathy with them and gets good cache-coherence, that's great, but if the language works against them and would make them write M[j,i] to get the same performance, they don't like it, so they keep writing M[i,j] and let the slowness be the other language's problem.
But speaking of arrays, one definitive advantage of Fortran is that it has built-in multidimensional arrays in the language. Which is very nice when writing code that needs them. In C many people resort to the Fischer-Price My First Multidimensional Array implementation where they allocate each row separately, which is of course horrible. (In C++ you can use libraries like Eigen or Armadillo which use expression templates and operator overloading to have sensible multidimensional array support even if it isn't built-in.)
It has to be row-oriented because the language allows you to take the address of each intermediate dimension, e.g. int *c = &a[3] gets you a pointer to the equivalent offset of b[30], and legally you can access c[0] through to c[9]. Accessing c[10] would be equivalent to a[4][0] and compilers will let you do it, but I think it's officially undefined behaviour?
- Procedure arguments are not allowed to alias. Similar to restrict pointers in C99+. This is often critical to allow loops to be vectorized, but the onus is on the programmer to ensure no aliasing or else you get UB.
- Unspecified evaluation order for expressions. E.g. C requires that "a+b+c+d" be evaluated as "((a+b)+c)+d)" and with floating point it can't do it another way due to rounding. Fortran can do e.g. "(a+b) + (c+d)" where each subterm can be computed in parallel, but again at the cost of slightly different results due to rounding behavior for floats.
- Old school Fortran lacked pointers which led programmers to program algorithms using arrays rather than fancier data structures, which cpu's love.
In principle there's nothing preventing a competent C or C++ programmer can reach Fortran level performance. In practice, might be difficult.
Of course, nowadays performance is much about designing for cache hierarchies (see e.g. "Data Oriented Design") where Fortran doesn't have a built-in advantage.