Was that a you-can't-do-that-in-c++ thing or slightly-faster-in-fortan thing? I'm always skeptical about the latter guiding major maintainability decisions on often-specious performance benefit claims.
1) built-in multidimensional arrays including Matlab-like array operations. That means every library supports the same format, it's standardized and convenient as opposed to the many formats in C++ Land.
2) performant defaults. When performance is more important than safety, Fortran programs are easier to write and maintain. Arguments are by default pass-by-reference, non-aliased (a major assumption Fortran compilers can usually make to optimize) and their intent as in/out/in out can simply be marked as such.
Fortran:
real(8), intent(in) :: foo
C:
restrict const * const double foo # if I remember correctly
A slight performance gain of 1% by using Fortran has a noticeable effect on long-term economic gains. (It was usually in the range of 5-8% performance improvement, but at the worst was 1%).
Thankfully, the reason I can tell you this, is because they tested it in the real world, splitting all transaction across a large-scale A/B test.
The real-world economic gains from the faster performance more than paid for the occasional development costs of a Fortran-familiar developer, hence why those systems persist in Fortran. They also scheduled re-assessment of this once every five years, knowing it might change one day.