Why does direct indexing not return an Option<T>?

I'm starting to have some 'introductory' conversations at work about the wanting to switch over from Python to Rust for some of our small/medium cli tools that we maintain for other teams. Looking to get a general speedup in some spots, and I've already made a few small POC's that show some pretty significant improvements and have some traction on the engineering side. Mainly needing time now to convince the boss to pay for the effort.

Going through the 'simple stuff' right now about talking about the strengths of the rigid type system, and the 'catch problems at compile time', and the - for the sake of the argument attempting to be made - 'better' error handling, the cake and the inclusionary eating of it etc etc.

I've been asked to put together some slides, and one of the bigger stories I want to cover in them is focusing on 'it can helps mitigate mistakes/ better error handling'. I want to refer to 'previous fires' to tell the 'had this been written in Rust, that scenario would have been a lot different/caught at compile time' sort of examples that would resonate with management.

Going back through the 'history of fires' i could recall, there's a little bit of everything that could be used, and specifically some VERY simple mistakes that caused problems.

Forgot to wrap that in a Try block? Rust better enforces handling the 'here be errors'.
Dictionary entry didn't exist? Rust doesn't let you forget None is possible.
Indexing into a list out of range? Actually...

I know .get() exists and the clippy indexing lint exists and whatnot, and I'm certainly going to use that in my sales pitch, don't worry.

I'm just curious why the 'lack of safety net' here for a very common/easy to cause a panic sort of thing? Why is direct index access into a Vec<T> etc. not 'unsafe' or at-least 'Its 'ok' that we don't need to worry about returning an Option<T>' when used?