My personal experience with Rust (vs. Go and other languages) is that there is something really magical that all the sigils and syntactic complexity give you: once you've internalized Rust's approach it's ridiculously easy to build an accurate mental model of what's happening in almost any piece of code. From the high level constructs down to generated assembly, Rust produces the most predictable code I've ever written. While not the same kind of simplicity you're describing, my experience is that the value of Go's simplicity is to give you a low overhead mental model. While Rust has some complexity, I personally find it to have the lowest overhead mental model of anything I've worked with, due to its predictability, explicitness, and strong conventions.
Granted, it definitely took some time for me to gain the experience necessary for this magic to occur. It's not really a "hack a quick thing together once every 10 years" kind of language.
It's hard to convey this without getting you to actually learn Rust for a few days/weeks/months, but it's certainly been my experience and I hear it all the time from other Rust developers.
The problem with people referring to more or less simple mental models, syntax, learning curves, expressiveness, etc is that they usually only focus on one of those at a time, when it requires multiple of them to get a good picture of how a language will work in practice for you, and in general.
As an extremely simple example of this, compare BASIC and APL in terms of the learning curve. If we examine it in isolation, BASIC is obviously better. But if we use multiple criteria, the answer becomes much more nuanced, as we can see what the steeper learning curve allows. For a less extreme, but still ultimately the same comparison, imagine Perl and Python, or Go and Rust. A simple mental model is important, but if one choice is less simple, the question should really be what are you getting in return, and is the trade-off worth it? Otherwise, you should just program in BASIC and be done it it.
I would compare Rust to Python rather than Perl. Like Python, Rust tries to have only one obvious way to do things, and avoiding TIMTOWTDI is a conscious goal.
I wasn't actually comparing Rust to either, I was using the common comparison of Perl to Python to illustrate the point. Perl is often denigrated for being hard to read, but I maintain that for the most part that's a function of experience with the language (learning curve). After you've internalized a few things, I think Perl is easier to read in many cases, because the sigils, which people often complain about, actually convey additional information in a succinct and recognizable way once you learn to read them correctly. It's what you get from having a steeper (or actually, longer, not really steeper) learning curve. But that's still not the full picture, as you've alluded to with TIMTOWDI, which is yet another spectrum on which languages can be compared.
I'm still in the early days of learning Rust, but from what I've seen so far I agree with that feeling of having a better mental model of the program. At first the language and syntax seemed overwhelming, but slowly its all coming together and what I thought was verbose syntax turns out to be incredibly helpful in terms of forcing me to think things through.
Several times now when caught out by the borrow checker, I've wondered, wow, how do other languages get away with allowing a situation like this.
This video series by the author of Rayon (and Rust core dev) was what first hooked me and made the syntax a lot more understandable: http://intorust.com/
I'm neither the OP nor a Rust expert, but I have found it quite easy to jump into and read/tweak both an established expert's code base and a new learner's code base.
Compared to Python: Rust is certainly a bit more verbose, due to being much more careful with performance, memory and precise types. But I find that the last one actually makes Rust easier to maintain. In Rust, I just have to look at the types being passes around, while in a complex Python code base, I might ask PyCharm for all calls to a function and work backwards, slowly try to infer what kind of thing a variable might be.
Go is much closer to Rust in terms of maintainability, but I haven't worked with it enough to say, because I didn't like other aspects of the language.
Granted, it definitely took some time for me to gain the experience necessary for this magic to occur. It's not really a "hack a quick thing together once every 10 years" kind of language.
It's hard to convey this without getting you to actually learn Rust for a few days/weeks/months, but it's certainly been my experience and I hear it all the time from other Rust developers.