I learned Rust only to abandon it afterwards. It's not worth the effort, especially if you already know Ada and various memory-managed languages like CommonLisp and Go. Although I'm sure sure these exist, I've never written a program that would benefit from not having a garbage collector.
If your program benefits from having a garbage collector (GC) — which I guess is a lot of programs — then by all means go for a GC-ed language. It's one less thing to worry about.
However, the garbage collection process itself sometimes introduce a noticeable pause in execution, which can be unacceptable in certain applications. Especially in critical real-time applications.
(That GC pause won't be a problem if your program mostly just waits for user input the majority of the time).
For an extreme example, you don't want your car's airbag controller to be paused for garbage collecting during a crash.
I agree, of course, there are some domains where garbage collection can be problematic, most notably game engines and DSP. High integrity applications and hard real-time systems like the airbag controller you mention usually go a bit further, it is often forbidden to dynamically allocate any memory, or at very least it may only be requested once at the start.
Pause-free GCs have existed for years, for what it’s worth. They do still have some CPU overhead in many cases, but it’s a question of throughput, not latency.
