One reason I don't see mentioned in much detail here:

In C/C++, arrays are stored as contiguous blocks of memory, the size of which has to be provided at creation. So, you might see something like

int arr[5];

Which means "allocate space for 5 integers, and put the starting location in the variable arr"

^{Technically in this case it's happening on the stack so it's not "allocated" in the same way, so just don't think about that}

Now, C/C++ has two special operators which do not exist in Python: & (address of) and * (dereference).

&foo, as the name suggests, gives you the memory address of the variable foo. Suppose it returns 12304568 - that means that foo's contents are located at the 12304568th byte in memory.

*foo gets the value at an address. *(12304568) would look at the 12304568th byte in memory and fetch whatever is there.

^{Not really, since we haven't specified a type, and that address is probably out of bounds and would cause a segmentation fault, so don't think about that either.}

The code *(&foo) is equivalent to just foo, since we get the address of foo and then get whatever is at that address (the contents of foo).

We could also do something like *(&foo + 1). Here, we get the address of foo, then look one unit over, and find whatever's at that location. The unit depends on the type of foo, and scales so that there's no overlap. If foo is an int, then we look 4 bytes over to find the next int. If foo is a double, then we look 8 bytes over to find the next double.

So, remember that I said that arr contains the starting location of our block of memory. This means that if we use *arr, we can check whatever is at the first int in our array. We can also look one int over with *(arr + 1). We can do this all the way up until *(arr + 5), where we're no longer looking in our specially-allocated block of memory - we might cause a segmentation fault here.

So, what are the elements of our array?

*(arr + 0)
*(arr + 1)
*(arr + 2)
*(arr + 3)
*(arr + 4)

As you might have caught on, this operation is so common that C/C++ has a special syntax for it. arr[n] is (in most compilers) exactly equivalent to *(arr + n)

If arrays were 1-indexed in C, then we wouldn't have this symmetry - either arr[n] would be equivalent to *(arr + n - 1), or *arr might produce a segmentation fault. Yuck.

Now, I'm just using C for syntax, but the same thing happens under-the-hood in just about every modern programming language I've ever heard of (and the ones I haven't) - even in cases like Python where we don't have direct access to the pointer arithmetic which makes it work. Exceptions to the rule usually break the first rule of symmetry I mentioned - in those languages, arr[n] (or similar subscripting syntax) is equivalent to *(arr + n - 1) (or similar dereferencing syntax).

Now, something Python-specific, which is a natural extension of all this, is negative indexes. Did you know in Python that you can use arr[-1] to get the last element of a list? We really have 10 names for a 5-element list in Python:

arr[0]; arr[-5]
arr[1]; arr[-4]
arr[2]; arr[-3]
arr[3]; arr[-2]
arr[4]; arr[-1]

If you know anything about modular arithmetic, this should seem nice to you: each name is congruent mod the length of the list. That is:

-5 % 5 == 0
-4 % 5 == 1
-3 % 5 == 2
-2 % 5 == 3
-1 % 5 == 4

You could also think of it as sticking the elements of the list end-to-end, with 0 in the middle:

-5 -4 -3 -2 -1 [0  1  2  3  4]
 a  b  c  d  e [a  b  c  d  e]

This symmetry is also broken if we have 1-indexed arrays.