Programmers should not try to access memory beyond the end of an array. They should not attempt to add ints and strings. They should not give a function a float when it expects a struct.
But they do. So we try to design languages in such a way as to minimise the likelihood of these mistakes going unnoticed.
Designing a language to minimize the likelihood of these mistakes is a motivation for language design, but usually far from the primary.
"Programmers should not try to access memory beyond the end of an array"
^ Right, and when they do, it's called a logical bug, something to be fixed. A programmer relying on the incidental but unspecified behavior of a function would be making a similar mistake.
But, we learned from C that the possibility of trying to access arbitrary parts of memory means that programs will end up trying to access parts they shouldn't. So, higher level languages like Python solve the problem by having memory-safe types like lists, which preclude the possibility of making this mistake.
Similarly, if we randomise the ordering of keys in the dict then it's impossible for a programmer to make the mistake (consciously or unconsciously) of relying on ordering.
At the cost of an additional processing step to scramble the keys. The balance between safeguarding ignorant or overactive programmers against the performance of a critical builtin type is not going to tip in that direction.
The whole reason we can even have this discussion is because a new algorithm was developed to give us the increased performance in the first place.
