As someone who is gung-ho and hopeful about Rust, but an outsider, I would also like to see that measured, well-argued article.
I thought this article had some truth in it, but in general I'm always frustrated by the implication (which pops up from time to time) that languages with similar goals are mutually exclusive and newer ones must kill the older ones or themselves die. C++ is a great language which has been on a tear of improvement for the past decade or so, and suggesting that something will, or even should, kill it is silly. But it's just as silly to suggest that it is pointless to target the same goals as C++ while attempting to improve on some of its weaknesses.
I think it is likely that Rust will not be the rocket-ship of growth that Go has been, because while Go has attacked a niche by largely upending its ground rules, Rust merely provides some (arguably) better trade-offs within a fundamentally similar paradigm. A better comparison will perhaps be Scala and Java, and that's something to aspire to – Java isn't going anywhere, but there are lots of great things written in Scala and plenty of opportunities to use it professionally.
Certainly, it will be interesting to see where or if Rust finds its place in the types of large and enduring projects that it takes to really get a language off the ground. I think a particularly interesting area could be the ever-expanding database sector. It's clear (perhaps to the chagrin of many) that there is room for many different database products attacking different trade-offs, and they are often written in C++ (or C) for performance reasons, but have high bars for robustness and concurrency for which Rust really may be a boon.
I do think a lot of Rust's adoption will hinge on its performance story, and that was the argument in this article, and others along these lines, that is the most compelling. To be in the running for projects that would otherwise be written in C++ (like the database projects I mentioned), Rust will need to have credible and competitive benchmarks. I think it has made many good choices about the fundamental trade-offs that have a huge impact on efficiency (like defaulting to value types), but that it remains to be seen if pervasive safety comes at too large a cost.