Renaming's not a bad idea; makes the code portable. Not that this needs that in particular...

Very concise, however there are at least 4 heap allocations here from creating new strings.
This solution should not be listed best practice.

Fire all the pancakes and send OP to culinary school

This is a clever use of Linq, however it's poor performance due to needless heap allocations and iterates over the array multiple times.
This should not be marked best practice.

How many heap allocations does it take to screw in a lightbulb?

AFAIK, it's because i64 implements the trait Ord, which contains those methods.

I didn't even think of that. I used if

To clarify what Mitchell wrote:

Because reduce returns Option<T>, its execution may be aborted any time with the ? operator which unwraps Result<T, E> and Option<T> and gives you the inner value, or propagates the error E / None to the calling function.

since no constraints for the arguments are given in the statement, add_binary(!0u64, !0u64) would cause overflow

Agree. Besides this operates on bytes, will fail on Unicode.

? operator short circuits None from inside the reduce closure if the i64 parsing fails in the map closure.

Could you please elaborate, how the code works in "reduce"? I assume that at some point the closure may end up with a None. Does "reduce" continue on "None" or aborts the reduce loop due to the "?" operator?

This will panic if the passed in string is empty.
I wouldn't recommend this as a "Best Practice" because it isn't clear when first viewing the code, that it will panic.