It’s not black or white. The critique is valid, there are some counterarguments too, and people may still find value in Rust (as they do in C++, and I won’t turn this into a vs. thread either). But I think that people need to be aware that Rust is not a panacea (no programming language is) and that it does tend to encourage a lot of the same bad habits and reaching-for-complexity problem solving, instead of using the right (often the simplest) tool for the job and fully comprehending the problem space. Concurrency is not always the answer, knowing when the simplicity of a lock is appropriate versus the complexity of lock-less, or wait-free architectures (which come at their own cost), or knowing how to architect to avoid the need for the lock in the first place (which is what a lot of good audio programming comes down to in some places).
As long as the programmer is aware and makes the choice consciously, then I say use whatever is best for them (could even be Java or JS for all I care), but it’s important not to get so enthusiastic about a language or features that the downsides, costs, and encouragement to avoid good programming discipline are forgotten.