"It just is." is not a good answer for adults.
Conventions and styles are in the eyes of the users. If the majority of users find using return intuitive, then it is a good style, regardless what the language designers' opinions. If the majority of users use the "return" style, then it will be the convention.
Rust is quite new, so at this point, there is not really much convention or "good/bad" styles, it is just recommendations and guidelines. You have the choice of following them (a particularly good choice when you don't have much of your own opinions) or ignore them as long as it is still correct (a not bad choice if you have sufficient self-confidence).
I am considering ignore this particular recommendation and would like to use return always. Return is a very important element of a function. In scanning a function, I often at first hunt for where the function returns and the return keyword helps a lot. With an expression language, everything is an expression, so how do I quickly figure out whether an expression is meant for flow control (return is a flow control) or a value? The example of the return buried inside if-else is a good example, as that increases the difficulty in identifying where the function returns.
In fact, this is my main critique of expression-oriented languages. Programming is not entirely math where all is about "what". A significant part of programming is about "how". Expression emphasizes "what", everything turns into a value; while flow-control emphasizes "how". I believe the main purpose of programming -- especially for a system programming language, the main objective is to describe "how". Of course I understand the value of expression-oriented design as it reduces complexity of a language. However, we need keep in mind that in programming, as it deals with practical problems, not everything is that simple, and by enforcing a simplified neat model, the complexity is merely shifted.
can't agree more :)