Yeah, the "Great minds" are still going to have a bigger lead when it comes to understanding language details, which are trivial semantic implementation concerns compared to understanding concepts. Programming itself is the boring part; it's merely transcription of concepts into machine-legible code. The concepts themselves, many of which are not even limited to the domain of computer science, are where all the interesting content is to be found.
When I say boring, I mean relatively; there is some "puzzle solving" merit to programming per se. But this is mere mechanics and minor compared to the experience of manipulating ideas into practicable forms before writing them out in code.
"Near C" performance is often not good enough, and usually misleading. You can write poorly performing applications in C, and certain benchmarks may favor or disfavor certain elements of a language. Generally they're created to be "similarly written" in all benchmarked languages, which may seem like the fairest comparison at face value. But what that means is that they are often naively written in one or more of the languages. Expertly written, hand-tailored-to-the-problem-domain C code is almost always going to outperform other languages by a significant margin, especially languages without manual memory management. You can do things in C like use arena allocators to significantly reduce memory performance overhead - things which require low-level control and a non-naive understanding of the problem domain. Garbage collectors can be quite performant, but they aren't capable of this kind of insight. Code that is written in C similarly to a garbage collected language will be similarly naive (another malloc call for each and every allocated thing, versus allocating out of an arena, for instance).
The most critical point you brought up is in finding good developers. Reminds me of this quote by Eleanor Roosevelt: "Great minds discuss ideas; average minds discuss events; small minds discuss people."
In this case, small minds discuss libraries/frameworks, average minds discuss language details, great minds still discuss ideas.
All of the best, most interesting, and most insightful programmers I have talked to express ideas in language and tool-agnostic terms, with written language, and only use code as an implementation or demonstration detail. This isn't to say that tooling and languages are not important of course, but the best programmers can pick up new tools and languages quickly and express their ideas in any given medium. If a programmer is limited by thinking in terms of the language(s) they know, they're basically a bricklayer. Still respectable, but they're doing tedium rather than manipulating the idea space.
Odin requires writing bindings (for the moment, this will likely be automated with third-party tooling), Zig actually has full first-class C importation.
In both cases the interoperability is excellent imo.
I can't speak to Zig as much, but Odin's type system makes working with C APIs much more of a pleasure than doing so in C itself.
Odin doesn't have CUDA-like GPU interoperability, so the benefits are going to be purely client-side. If you were working in say OpenCL + C the benefits are more obvious, with CUDA you're not going to get an analogous experience.
I would say in my experience that Odin is definitely preferable as a client language for the simple reason that it's a nicer systems programming environment than other languages, but it's not (at least right now, future developments could always change this) equipped to run native GPU code.
Things like SPIR-V and "shader ASM" open up some interesting possibilities once the custom backend is implemented, but the complexity of integrating GPU execution means making it a first-class feature it probably unlikely.
When I say boring, I mean relatively; there is some "puzzle solving" merit to programming per se. But this is mere mechanics and minor compared to the experience of manipulating ideas into practicable forms before writing them out in code.