I have been playing with Rust for a few weeks now, so I can give a few reasons
not to use it. What I will write may sound overly negative, but keep in mind
that those are only reasons not to use it, in general I found a lot to like in
Rust.

Unsurprisingly most of issues described below, boil down to Rust not being
mature yet, and are perfectly fixable. However, fixing some of those will break
backward compatibility one way or other and require effort that would be
unnecessary otherwise.

Language is underspecified. In what order are subexpression evaluated in Rust?
Unspecified yet, in fact it is even worse than that, it differs between borrow
checkers (which I think uses the most useful one given Rust syntax: right to
left behaviour), while code generation assumes left to right order.
https://github.com/rust-lang/rust/issues/28160

What can you do with pointers in unsafe parts of code so that everything is
still well-defined. There does not seem to be real answer to this question yet:
https://github.com/rust-lang/rfcs/issues/1447

What does Rust guarantee with respect to lifetimes? In fact it guarantees much
less than what would you expect. Take for example a drain method of a Vec.
Drain gives you an iterator that moves elements out of a Vec. Naive
implementation would leave Vec in a inconsistent state while drain iterator is
still alive (because some of elements are already moved from), but restore Vec
to a valid state in destructor of drain iterator. It appears to work because no
one can touch Vec while drain iterators still holds mutable reference to it.
Except it wouldn't work, because Rust does not guarantee that drain destructor
will be executed, in fact in perfectly safe code it may not be executed at all.
Surprisingly a borrow of a mutable reference may outlive the lifetime of a referent.
At least it seems that Rust guarantees that those references would be
inaccessible.
https://internals.rust-lang.org/t/are-memory-leaks-considere...

There are quite a few language issues like this, and in general I found it very
hard to find what exactly Rust semantics is.

Rust sends mixed signals about panic. On one hand it try to tells you that code
that panics is probably badly broken, and may have left data structures in an
inconsistent state, so you should not even try to access them. And Rust tries
to ensure this to some degree by putting roadblocks on your way if you think
otherwise (see Mutex poisoning, and strange things like AssertRecoverSafe you
have to use when recovering from panics). Except in reality, all your
desctructors already do access all those data structures. It seems that all
those roadblocks are quite pointless.

Running out of memory aborts program. This is I think quite a bad decision (it
seems that this may be a temporary one) for a language that have exceptions in
form of panic. Not many programs need to handle out of memory situations, but
handling those in programming language with exceptions and RAII is quite easy,
and mostly boils down to: don't perform dynamic memory allocation in
destructors. This is a step backwards from C++.

Bugs, bugs and more bugs. Rust not calling your desctructor for variables in
the same scope after panic, still there after more than a year:
https://github.com/rust-lang/rust/issues/14875

Borrow checker is interesting, certainly prevents you from writing buggy code,
but also prevents you from writing code which is perfectly fine. In certainly
does not play nice with ideas which are very common in C++ world, any STL
algorithm + container would be a good example. I am still not sure if it is
worth the effort, it seems to prevent problems that I don't commit in C++
anyway.

Immature state of ecosystem, libraries, documentation, ... .

In general you probably will not be as productive in Rust now as you would be
in other languages. If you are interested in developing those libraries that
are currently lacking, having some impact in how Rust language may look in a
future, then Rust community is certainly great. But a lot of people have
different priorities.