When interfacing with external libraries with C APIs, whether Rust helps or not depends on how much Rust code you're going have beyond just interaction with the APIs.
The downside is that you will need Rust bindings, which are Rust equivalents of .h header files, and keeping them up to date and usable for complex C APIs is a hassle. For C++-only APIs it's a big challenge. If you're doing very little work other than calling 3rd party APIs, that's extra effort for little benefit.
The upside is that Rust wrappers for such libraries can improve safety and ergonomics, even when wrapping C code. That's because Rust's type system can express more information about the interface, and e.g. ensure data is always initialized and handles are freed correctly. Rust bindings can encode libraries' thread-safety constraints in a way that the compiler understands, helping to use them safely in multi-threaded programs. So if you plan to have a lot of custom code, you can benefit from the extra correctness and productivity that Rust adds.
Rust has mature Python bindings PyO3 that people successfully use to extend and accelerate their Python programs.
Regarding hiring:
There's a catch 22 situation where many programmers want to switch to Rust, but don't see any serious Rust job openings, and companies that would like to use Rust, but don't see "Rust" candidates. You have to take a risk to break that loop.
It's ok to hire C or C++ programmers who want to learn Rust, and they don't have to be senior in C/C++. You can also hire programmers with experience in your domain who have little Rust experience. That's because Rust does a lot of "hand holding", and you can tell inexperienced programmers to avoid writing unsafe code, so they will at worst write code in a suboptimal/non-idiomatic way, or get stuck on compiler errors, but they won't break the software in some painful way (like memory corruption or threading heisenbugs).
It's very helpful to have some experienced Rust users in the company to help others get unstuck, and help guide what architectures are a good fit for Rust. Rust has some gotchas that are very difficult to novice users, but are easy to solve for someone who knows the right approach. Rust is productive when you write things "the Rust way". With guidance from someone experienced in Rust, others can become productive pretty quickly.
Rust produces native executables, which are pretty self-contained, and don't require Rust installed. The executables are compatible with a lot of C and C++ tooling (debuggers, profilers, sanitizers, etc.). It has good support for mainstream platforms. It can also target WASM and 32-bit embedded platforms. Rust's standard library adds about 300KB to executables, so tiny devices need special care — it's possible to write Rust without its standard library, with code as small as you'd get from C++ and clang.