But I can assure you, the vast majority of legacy Fortran is not vectorizable. At least not without a bit of refactoring.
Oh and did I mention, most of this legacy code was hand optimized for memory utilization. You see, back in the day 8k of memory was cutting edge HPC and about half that went to the OS and compiler. Well we all know, everything is a balancing act between time and space - the old timers traded time for space just to be able to do the computation at all on the hardware they had.
1) Nobody puts "restrict" everywhere, and in C it can be very dangerous to do so unless you're exceedingly careful.
2) The fact that few codebases use it means it's riddled with compiler bugs even if you are exceedingly careful. Just look at how many times Rust has had to disable noalias due to LLVM bugs and regressions.
Just because Fortran does the equivalent of implicitly using restrict everywhere does not mean the compiler actually statically checks for abuse. You can just as easily write bad pointer aliasing code in Fortran and depending on what optimization level you built with you may or may not experience memory corruption and/or segmentation fault at run time.
So the standard just says "don't do it, LOL" but then you are able to write Fortran violating this. Which is how you end up with bugs that go away when you switch optimization levels.
In fact, only C++ is able to confortably beat Fortran, despite not having official support for restrict, because of the stronger type system and compile type metaprogramming that offer optimization opportunities out of reach to C compilers.
Usually HPC places like CERN and Fermilab don't migrate their aginging Fortran code to C, rather C++.
What you end up with is a language with a reputation for being faster for computation