Method auto-(de)ref (and lack of it) in RFC 132 ufcs

I accidentally kind of buried a lede in my previous post. To directly answer the OP question, you need to look into prehistory a bit. RFC 241 includes a section:

When auto-borrowing was removed, this reasoning difficulty was cited as a major motivator:

Code readability does not necessarily benefit from autoref on arguments:

let a = ~Foo;
foo(a); // reading this code looks like it moves `a`
fn foo(_: &Foo) {} // ah, nevermind, it doesn't move `a`!

let mut a = ~[ ... ];
sort(a); // not only does this not move `a`, but it mutates it!

Having to include an extra & or &mut for arguments is a slight inconvenience, but it makes it much easier to track ownership at a glance. (Note that ownership is not entirely explicit, due to self and macros; see the appendix.)

This RFC takes as a basic principle: Coercions should never implicitly borrow from owned data.

[...]

In today’s Rust, ownership transfer/borrowing is explicit for all function/method arguments. It is implicit only for:

• self on method invocations. In practice, the name and context of a method invocation is almost always sufficient to infer its move/borrow semantics.

• Macro invocations. Since macros can expand into arbitrary code, macro invocations can appear to move when they actually borrow.

This can let us infer that at the time autoref was directly tied to &[mut] self receivers for method invocation. I'd hazard a guess that the ability to select <&T>::method on a receiver of type T was not a designed capability but was just a side effect of the implementation choices. Notably, the self lookup process was described as some number of autoderef followed by a single autoref; it makes sense for that autoref to be for the Self to &Self coercion.