Just looking at the language myself, but it seems that it treats out-of-bounds array access as a non-recoverable bug and panics [1, 2], whilst map access returns Option [3]. Exceptions are a language construct only to enable Java compatibility and not recommended otherwise [4], but that's not to say you couldn't implement your own try/catch using the effect system. `r` is a region variable as the sibling comment says.
I agree with OP that this seems a little unfortunate, even though it's pretty par for the course.
"Bugs are not recoverable errors" is such a fuzzy idea. On the one hand, indexing an array with an out-of-bounds integer could just be considered a program bug. On the other, the point of making the indexing operation return an optional value is to force the program to handle that scenario, preventing it from being a bug. One of the examples they give of a "recoverable error" is illegal user input, but in the case of "the user enters an index and it might be invalid", the language does nothing to keep the recoverable error from turning into an unrecoverable program bug.
It does seem to depend highly on the context in which the array is used. Strictly defined algorithm with an off-by-one: bug. User-defined indexing as you say is a counter. I suppose it is hinging on arrays being used in less dynamic contexts where you're likely to know the length, so to save you from handling all the Nones. I think I'd prefer a parallel api that returns Option, so you don't need to duplicate the bounds checking.
[1] https://doc.flix.dev/chains-and-vectors.html#vectors
[2] https://flix.dev/principles/ See also "Bugs are not recoverable errors"
[3] https://api.flix.dev/Map.html#def-get
[4] https://doc.flix.dev/exceptions.html