Oxide is using Rust for everything, from "firmware" up through "the backend of our APIs." I linked to a talk some of my co-workers gave about the API and control plane stuff here
https://news.ycombinator.com/item?id=26253928 . We are still early enough that a lot of this is not public, but eventually everything will be open source.
Yes, the technologies you've mentioned are good at those things. But what matters is more "is this technology viable for this task." This is because requirements are different from team to team. For example: imagine I work at a place where all of our software is written in Java. Let's say that Rails is 100% good for building a website, and Java is 90% good. For me and my team, choosing Java may make sense, even if it, in some sense, is not the globally best option. It's actually not the best option for me, because I have like, a bonus for Java because I already have a ton of people that know it, and consistency matters. But if you don't know Java, but do know Rails, then choosing Rails is the right choice for you. We can disagree on the "best" choice, and both be right.
(Now, if there was a tool that was 90% good for a task, and Java was 10% good, that might outweigh the consistency and various other requirements. And there's always something that a given tool is 0% good for.)
Reducing Rust to "only good when I can't use GC" is not appreciating the full things that Rust offers, which is of course, what you're asking about. Many people love the tooling, the type system, the performance, the consistency, the low resource usage, the concurrency tools. The lack of GC is incidental, in a sense. For some thoughts on this, from someone who is on the language team: https://without.boats/blog/notes-on-a-smaller-rust/ My main point here is that, Rust doesn't have to be the globally best choice for it to make sense to choose Rust, it just has to be a viable enough choice, and that can depend on a variety of individual factors.