One-index based addressing of items was the norm in most of the mathematics or physics books written before WWII, but even then there were exceptions, e.g. for the components of a quadri-vector or a quadri-tensor, i.e. for spatio-temporal vectors and tensors, it was already common to use the indices 0, 1, 2 and 3 for the temporal component and for the 3 spatial components, instead of the indices 1, 2, 3 and 4.
However, this tradition is worth nothing, because before automatic computers the use of decimal numbers instead of binary numbers was also the norm, like also the use of big-endian numbers instead of little-endian numbers. Having to actually implement the computational operations in hardware has revealed that many such traditions were sub-optimal.
Despite the fact that among my programming interests the scientific-technical computational problems have always been on the top and I have started programming with the Fortran language, I have always recognized that using 1-index based array addressing is inferior and any programming language that uses this convention makes a mistake, because this increases the chances of programmer off-by-one errors, by requiring more complex index expressions in many cases.
If anything, my opinion is that programming languages should not support any of such obsolete "norms", but they should go further in replacing them.
For instance, I believe that for integer constants and printed numbers it is still OK to use decimal numbers, because this simplifies mental computations for most humans, who have memorized the multiplication table of decimal numbers and because the conversions between decimal and binary integer numbers are exact, so it does not matter which base is used to display them to humans.
On the other hand, I believe that for floating-point constants and printed numbers it is a mistake to use decimal numbers, instead of using hexadecimal numbers for the significand and decimal numbers only for the exponent (like when printed by printf with the %A or %a conversion specifiers). The reason is that the conversion between floating-point decimal and binary numbers is slow and inexact, introducing rounding errors, without providing any advantage for a human who reads the program text or a table with results.
Comparing hexadecimal floating-point numbers is actually faster and easier for a human reader, than when working with decimal numbers, because the numbers are shorter. Except for comparison, a human will not do any other exact mental computations when reading a set of floating-point values. (At most, when looking at a column of numbers displayed as fixed-point values, a human might add one or a few of the digits, to check that their sum matches the corresponding digits in a displayed total value, but unlike multiplication, addition is almost as simple for hexadecimal numbers as it is for decimal numbers.)
Approximate mental computations are also easier to do with binary floating-point numbers than with decimal floating-point numbers, if you understand how to do them (which is by using logarithms in any mental computations; this is true for both binary and decimal floating-point numbers, because approximate conversions between numbers and their logarithms are very easy to do mentally, as any engineer working with decibels knows). Doing just the simple operations with exponents provides already a better accuracy than for decimal numbers, because an octave is smaller than a decade. For additional accuracy, it is usually enough in mental computations to approximate the floating-point values to 3 points per octave, in which case the approximation error is about the same as when doing approximate mental computations using decibels.
In decades of programming, I have never encountered any case when I would have wanted for my program to contain decimal floating-point constants, or for any result to be printed as a decimal floating-point value, but I have encountered the opposite case, when a programming language annoyed me because it forced the use of decimal floating-point constants, which introduced undesirable rounding errors, so I had to use equivalent integer constants and use something like memcpy to convert them into the desired floating-point numbers.