Amazing! That did the trick. 
Running with your modified twins_sieve produces times that are < 1% difference up to at about 10^12 and ~4% up to 10^13 (doing a quick test on a "noisy" system).
I compiled using:
RUSTFLAGS="-C opt-level=3 -C debuginfo=0 -C target-cpu=native" cargo build --release
and just
cargo build --release
From just minimal testing, there doesn't seem to be any statistically consistent speed difference, though the later creates a tad smaller binary.
This actually makes me feel better, in that I was correct in thinking Rust could be faster AND I just didn't know how to do it. That's because the official documentation provides no good tutorials|examples to let you know of the existence of these techniques and how to apply them, and when|why.
I think the whole concept of what is unsafe needs to be presented differently, such as has been done by @cbiffle here - Learn Rust the Dangerous Way - Cliffle - and in this thread:
This topic needs to be presented less dogmatically. Using unsafe techniques doesn't have to mean your code is necessarily dangerous, and will blowup. It should be presented as @cbiffle does, and explain that it is available to use, but be careful, because the compiler won't automatically bail you out.
Thank you @raidwas for letting me know about this technique, and examples how to apply it. I think allot of other people have learned something from this exercise too. (The only other question in my mind is, is there still some way to design|implement the code to get similar improved performance using only strictly safe techniques?)
I would really encourage a more objective discussion of these things in the docs, blogs, videos, etc. As in this case, this can really make a significant performance difference in numerical heavy applications, where the bounds of the problem are clear and defined, so the programmer can squeeze out the last possible microsecond of performance.