It could just as easily throw a compilation error to index a constant with an array rather than the other way around. I don't think this works in Rust even if the resulting machine code for array indexing is the same.
The main reason is that in C, "indexing" an array is purely syntactic sugar for pointer arithmetic, which itself is commutative; that is. ((A)[B]) is equivalent to ((A)+(B)), which itself is equivalent to ((B)+(A)) (assuming one of them has an integral type and the other a pointer to complete object type).
Now, of course an array type isn't a pointer type, but as "indexing" isn't one of the very few cases where an expression that has an array type isn't converted to an expression with a pointer type, you aren't really indexing an array, but a pointer to its first element.
Another way to look at it is that C syntax was designed to be extremely simple to parse, and C semantics to simplify code generation. Early C compilers immediately generated code as they parsed each expression, keeping minimal state. (No AST!) Also consider that in B the only data type was the machine word, so the type of the operands were irrelevant to the code you generated. In early C the biggest difference was structures, which required some minimal bookkeeping (very minimal when all members were in the same namespace), but a struct dereference is just syntactic sugar for an (address + offset) expression, so underneath the covers the compiler was still just chewing through identifiers, left to right, and emitting simple assembly for addition and multiplication, because each identifier was just a symbol for an integer.
So index[array] isn't an historical accident. It might not have been deliberate, but it follows naturally from the nature of the language.
Go very much follows the same discipline. Speed and simplicity of compilation constrain the syntax, most notably the lack of generics. Goroutines, channels, etc, only require minimal syntactic and compiler support. Contrast that with Rust--Rust front loads everything into the parsing phase--lifetimes, async, etc. Deep AST analysis and transformation is everything for Rust. Of course these days people abhor even the possibility of allowing something like index[array], so even a compiler like Go goes out of its way to disallow it.
I see no reason why this should be obvious; it's just a historical quirk of array indexing in C being a literal translation to pointer arithmetic. In C++, for example, there is no way to support this with the subscript operator.
