If you had this belief say, 10 years ago, and because of it you decided to write your serious application in say, Java, you would have been in for a huge unexpected surprise last year when the now infamous log4j vulnerability was made public.
See, having memory safety did not prevent the language from causing arbitrary code execution vulnerabilities. Having the log4j project be open source and popular did not prevent that either (so much for the "enough eye balls" theory).
Going back to Odin, when I think memory safety is not as big a concern as people make it out to be:
Your only source of concern is C.
This would be like judging SQL statements as fundamentally unsafe because websites written in PHP tended to (specially in the early 2000) be written in a very unsafe manner where user input was put directly into SQL strings.
The lesson that people took is not to throw SQL out the window, but to properly sanitize user input before passing to the queries, and to never use plain string concatenation when doing that.
So for manual memory management, the lesson to take from the vulnerabilities that C has caused is not that manual memory mangement is bad. It's that you need some facilities in the language to minimize the chance of them occurring by several orders of magnitude.
Odin does this by providing the slice type (and string type) that have their length known and providing several custom allocators out of the box.
The cool thing about the slice type is not just that the length is known: the language provides facilities for iterating over the slice that automatically never goes out of bound:
for item, index in slice {
// do something
}
This, and providing a "string builder" type into the core library that lets you dynamically construct a string in a safe way (you don't have to write the code to grow the string dynamically because it has already been done).
These features make the "fear" of unsafe memory access largely unwarranted anymore.
What remains is a matter of what attracts you to programming: are you interested in having explicit control over a system to make it do what you want, or are you more interested in expressing some abstract ideas in an abstract mathematical virtual machine? If the latter, you might find Haskell or Lisp more appealing.