I wonder how it can be a security issue, as arr[UINT32_MAX] should likely ( if not always ) be a segfault, but it doesn't read or write valid memories.

If index is UINT32_MAX, it triggers the index > numArgs check, since numArgs is always 8 for the terminal module, which leads to arguments[UINT32_MAX] never being accessed.
However, an attacker would need to control what index - 1 resolved to much more than is possible here to be able to exploit the arbitrary read, which is not possible due to checks in getArgumentIndex, so it's not an exploitable security issue, just a bug.

I meant, the type of index is uint32_t, when index == 0, index - 1 is equals to UINT32_MAX.

I see what's going on here. You're right that when index == 0, index - 1 = UINT32_MAX, but that bypasses the earlier check that index > numArgs (where numArgs is 8 in the context of this bug). In other words, if getArgumentIndex returns UINT32_MAX earlier, that index > numArgs check would be triggered and the dereference would not occur, but since index is 0, the check is not triggered and the dereference occurs with a value of index - 1, which is in that case UINT32_MAX. This causes the segmentation fault, which as I said earlier, I don't believe is in this case exploitable as a security issue, and is just a local denial of service bug.