To be perfectly honest, I think this is a general sign of the lack of experience.
Specifically when you are dealing with something not covered by the median CS course at universities or the mainstream of software engineering (eg., enterprise web application development), your architectural problems will come less and less from the language side, and much more from the domain itself.
I've been working for a small personalized medicine company for over 3 years that sports a dedicated IT development team for an in-house administrative site; I'm not part of that team. In addition to software engineering, I have a background in bioinformatics and data science, so I'm more on the science-y side in the company, helping non-coder scientists (biologists, geneticists, chemical engineers) with the automation of infrastructure and statistical methodology of their research.
I have to tell you, the majority of the dedicated IT guys (some of whom have been working for the company for 5+ years) still didn't really grasp how to design the software well, where by "well" I mean that it's usable, versatile, easy to modify, and expressive. For example, they are still designing their databases around serving the UI, rather than with the domain model in mind. It is the norm that I have to build my own versions or projections of the database before I can answer any sort of research question.
Having domain knowledge (and wanting to use it) is invaluable. There is not going to be any sort of substitute for it. Not even Rust's type system. Not even Rich "Lisp is superior" Hickey's quite frankly weird hot takes on programming. You have to know what you are doing, and this necessarily entails understanding the purpose and the users of your software. This is a much overlooked detail that I think should be considered of as high importance as good language design.
And now for the Rust part. I have written several pieces of software in Rust at this company. From small utilities (eg. a custom binary compression format) to large, multi-month projects (eg. a service that takes anamnesis information from clients and spits out a large number of automated diagnoses based on multiple decades' worth of clinical research).
One time Rust's type system saved my ass miraculously. The project requirements grew very complex, but did so gradually. The medical professionals were at first unable to mention crucial details about the structure of the data and what internal consistency constraints it had to satisfy. As we did a lot of back-and-forth, I developed the diagnostics service and they came back with errors and fuether requirements in it.
Had I not have access to a strong type system enabling me to follow best low-level coding practices, I would have been completely unable to navigate such a mess. Fortunately, at the very beginning, I was principled enough to start encoding every little detail into the type system, creating custom traits, newtypes, and helper functions for eg. checking that a particular question wasn't accidentally answered multiple times in the DB (the DB does not have such consistency checks encoded in its schema, it's severely lacking normalization in some aspects). And indeed, this came very handy when refactoring was needed; I quite honestly don't think I could have released a coherent piece of software had I started writing it in Python.
So: no, Rust is not a panacea, and not a substitute for knowing your domain. It won't make complex domains magically "simple". It will "only" help you navigate the complexity of your domain without making huge errors.