A lot of the arguments in this post can simply be rebutted with basic abstractions. Things like "Dynamically allocating and deallocating ... 2D array" is easy in C++. You could easily have someone define a MathArray<Type, Rows, Columns> class and turn this messy fortran code:

    real, dimension(:,:), allocatable :: name_of_array
    allocate(name_of_array(xdim, ydim))

Into something that looks like

    auto *my_matrix = new MathArray<double, 10, 10>();

The code the author showed demonstrates a lack of understanding of C and C++. Even if you restrict it to C your matrix code should look something like this

    typedef struct {
        size_t rows, cols;
        void values[];
    } mat;

    inline mat *matrix_make(size_t rows, size_t cols, size_t value_size) {
        mat *m = malloc(sizeof(size_t) + sizeof(size_t) + (rows * cols * value_size));
        m->rows = rows;
        m->cols  = cols;
        memset(m->values , 0, rows * cols * value_size);
        return m;
    }

While that code may be complicated the physicists only need to see....

    mat *matrix = matrix_make(10, 10, sizeof(double));

And if you'd really like you can hide the sizeof via a macro...

    #define MATRIX_MAKE(r, c, type) matrix_make(r, c, sizeof(type))

For me "real, dimension(:,:), allocatable :: " is much more complicated than "matrix_make"

Many of the issues people see in the speed difference between Fortran and C code will likely be based on their misunderstanding of how Fortran actually does their data layout and a misunderstanding of how the computer hardware (and what you're describing to C) to do. This "Double array" that was defined would never be allowed in production code. The amount you'd be hitting the OS for even small allocations is crazy.

The arguments for Fortran, as far as I'm concerned, are:

   1. We already know it
   2. We're not going to get grant money to rewrite a library
   3. We've built a bunch of computer clusters and have to justify what we spent (rather than buying 2 GPUs for your workstation)
   4. We've all spent a lot of time learning how to use MPI that we're never getting back.