There are two kinds of scientific programmers, those who use scientific libraries and those who write them. Users of scientific libraries are usually scientists, not professional programmers, and therefore need a simple language. Simple implies interpreted, which implies slow, but this can be mitigated by having the core algorithms written in a lower-level language and exposed as a vectorized library in the higher-level language. Numpy and Scipy do this for Python. R and Matlab have a similar design built in.
Rust will never compete as an environment to use a scientific library. (Biologists will not be writing Rust code anytime soon.) However, Rust has the potential to change the landscape for those who write scientific libraries, which are currently written in C, C++, and Fortran.
I won't address the specific issues in the article, but my experience with Rust so far has is that it is not quite there for writing scientific libraries. I tried to write a simple linear algebra library in Rust (mainly to learn Rust and test its suitability). I succeeded in learning Rust thanks to the helpful community and excellent docs, but failed in writing the library. I ultimately couldn't find a way around a compiler oddity (posted on SO and Discourse) that shows up in a definition of an abstract Matrix type. My final impression, perhaps inaccurate, was that the code paths needed for scientific programming were not as well traveled as those needed for systems programming. I come back every couple months to update my copy of nightly to see if the error changes.