But, given that dovecot just got a glowing security audit, perhaps there are other software projects that should be prioritized higher in the "rewrite everything in rust" list..
All those languages are garbage collected or use automatic reference counting. Rust is unique in using its type system to automatically allocate and free memory. For the use cases where the overhead of GC is too high - Wich are the same use cases that generally call for C or C++ these days - Rust has no competition. I think this explains why Rust is still in the explore phase.
It's hard to take Eric S. Raymond seriously. He starts by claiming to be responsible for the open source development model, continues to make some generic remarks about library quality that applies equally to many other established languages (including C), then has the gall to offer advice to the designers of a language that he is openly struggling with [1].
His arguments aren't all wrong, but it's weirdly presumptious to level them so unequivocally at a new language/community that is still finding its feet and whose adoption rate hasn't even reached the point where you can talk about library curation/fragmentation being a huge problem. One has to give Rust some slack just for being young and immature.
You also have to give Rust some slack for just being more different and complicated than the languages you are used to. If you read his previous post about Rust, it's clear that he's blaming Rust for his inability to grapple with its fairly advanced concepts, and his complaints mostly amount to knee-jerk reactions, not carefully reasoned criticisms.
While it's true that Rust doesn't offer a learning experience that's as friendly as Go, by far, Go has the benefit of having a head start of several years, a larger organization funding its development, and of being a much, much simpler language. Based on his skill level, it sounds like Go would be a better fit for him. (I use Go myself and see a huge benefit being that it's easy to learn for any developer, not just highly experienced ones.)
Criticizing a low-level language that makes it cheap and easy to directly call C APIs directly for not providing special syntax for select/kqueue/epoll when he could just call epoll if that's what he wants makes it clear that he wants to be writing some other, higher level language entirely.
It tells us nothing interesting about whether or not Dovecot, a project that wants low-level direct binding to POSIX APIs, is not suited for Rust.
On the one hand, the audit is a bit of a counter to "writing C is the same as writing unsafe code". On the other hand, there are a number of potential efficiency (as in, time-to-develop, maintenance effort required) gains for using a language, such as Rust, which provides the abstractions used in the C code out of the box and "for free" (in terms of implementation time--not necessarily execution performance). For a mature and stable project, especially one that has already built-in the effort to set up and maintain the appropriate abstractions, the effort to re-write is probably not worth it.
"Rewrite all the things in Rust" is asinine in general, but in this particular case it's especially bad. It would be much better to focus on C and C++ projects with actual problems.