When I saw this decision my first reaction was "Well, that was a promising language. Shame about that." I can't be the only one...
Additionally, for a variety of reasons Rust's tasks were not smaller than OS threads, because they need to be bigger for a lot of things (calling into C, for example) and segmented stacks were found to be much too slow. Go gets around these problems by allocating a new stack when the current one runs out of space, but doing that properly requires being able to trace all the pointers into the stack to figure out where to transfer them--in other words, it requires a garbage collector :) So that solution wasn't really viable for Rust.
Finally, having to support both concurrency models required Rust to make significant sacrifices in its libraries, in both complexity and performance. Go was able to make the decision to focus entirely on green threading, but Rust did not take that approach, so it was stuck in a "worst of both worlds" situation.
It is possible that there is a better solution that avoids all these problems, but it will have to be found outside the main Rust tree.
Also, it doesn't _preclude_ green threads. As others have mentioned, Rust is low-level enough that all of this is a library issue, not a language issue. You can write whatever concurrency primitives you need, and they'll be no less privileged as the ones the standard library gives you.
Go's concurrency features are nice if it's your kind of thing, but will get in your way when hitting that "last mile" of performance. For example, if you were to implement something like haproxy, you would probably want to use Rust over Go for performance.