> Mozilla tried to parallelize Firefox’s style layout twice in C++, and both times the project failed. The multithreading was too tricky to get right.

That is a damn good reason to choose Rust over C++, even if the Rust implementation of the "same" thing should be a bit slower.

It's a good reason to choose Rust over C++ for that application, and others that share its characteristics. (Or, more to the point of the article, it's a good reason to declare that Rust is faster than C++ for that application.)

It doesn't provide a lot of evidence in either direction for the rest of the vast space of potential programs.

(Knowing C++ fairly well and Rust not very well, I have Opinions, but they are not very well-informed opinions. They roughly boil down to: Rust is generally better for most programs, largely due to cargo not Rust, but C++ is better for more exploratory programming where you're going to be frequently reworking things as you go. Small changes ripple out across the codebase much more with Rust than C++ in my [limited] experience, and as a result the percentage of programming time spent fixing things up is substantially higher with Rust.)

Only if it is repeatable. We have no information on what they learned in the two failed attempts - it is likely that they learned from the failures and started other architectural changes that enabled the final one to work. As such we cannot say anything about this.

Rust does have some interesting features, which restrict what you are allowed to do and thus make some things impossible but in turn make other things easier. It is highly likely that those restrictions are part of what made this possible. Given infinite resources (which you never have) a C++ implementation could be faster because it has better shared data concepts - but those same shared data concepts make it extremely hard to reason about multi-threaded code and so humanly you might not be able to make it work.