@Centril You've retracted pure specifically but I feel like I owe you some answers, and for that matter I have a more general point to make regardless of the specific keyword used.
This is true. This term specifically is not popular (or even known) outside of Haskell circles, so the advantage of being a familiar term only applies to Rust programmers with Haskell background (a numerical minority), while for all others it's a completely foreign term that has to stand on its own. A term with Haskell lineage can of course be good at standing on its own — "associated type" is — but that is a merit of the term in question, independent of its lineage.
I have a rough idea why it might be a sensible name for the Applicative operation. But without referencing that (very strained) analogy, I don't see how any sense of the word "pure" is at all related to "wrapping a value in a container". Even in Haskell, "pure" just for wrapping something in a container, divorced from the notion of computation that Applicative has, is an odd name. In other words, how can a programmer make sense of the term without learning about, and constantly thinking in analogy to, Applicative?
Independently of the specific keywords used, it seems to me that replacing return in Ok-wrapped functions is a cure worse than the disease, in the sense that (at least in the little snippets shown here) it doesn't look significantly nicer than what you'd write in Rust today. I understand the objection to overloading return to do special wrapping, but adding yet another keyword that is virtually identical to return (and asking programmers to always choose the right one) seems like a big change to surface syntax for rather little gain.
It also jeopardizes at least one advantage of Ok wrapping, the edit distance when making a function fallible: You'd have to change all early returns and touch the tail expression(s), much as if Ok-wrapping did not exist, only now you're doing return -> $new_keyword instead of adding Ok(..) or Some(..) around the returned expressions.