The intended reading there, AFAICT is "anyone can create (this type of software)" (which was effectively not true before) - that's not to say they can easily or quickly do so, but that they can reliably do so.
The whole point of Rust is that before there were two worlds:
- Inefficient, garbage collected, reliable languages
- Efficient, manually allocated, dangerous languages
And the mark of being a good developer in the first was mitigating the inefficiency well, and for the second it was it didn't crash, corrupt memory, or be riddled with security issues. Rust makes the trade-off instead that being good means understanding how to avoid the compiler yelling at you. (In reality, these are all eventually the same actual skill: understanding how to design programs to avoid mismatching the hardware.)
In other words, with JavaScript, you need to be a genius aware of a whole bunch of crazy tricks to scrape out the last bits of performance (and that's one of the better cases!), while with C you need to be a genius aware of every possible angle of undefined behavior to be reliable, with Rust you just need to be patient
This does not mean Rust is ideal, not even that it's great - if the explosion of interest around GCed languages in the 90s and the current interest in Rust are reflections, then we should see a lot of competitors popping up over the next 20 years or so - we're already getting the "actually the old way can do this fine" now with "memory safe C forks" that are actually just adding a GC, and C++ is looking at adding borrow checking - but there's not any clear precedent that borrow checked languages will completely replace the use of unsafe or GC languages no matter how smooth the experience is made (hopefully, though, it replaces unsafe languages for at least security relevant code!)