I've always felt an added burden when reading method code which doesn't use a predictable receiver name. Especially as you need to see clearly where a method alters its object's state.

Worse still when the name is one letter among other single-letter names!

The wiki page is a style guideline, and as it says the Go style is not to use names like self or this for method receivers.

I believe that the explanation is accurate. At least in C++, virtual methods are special, and the name this has a special meaning: it refers to the real object with virtual methods attached, not to the object whose type appears in the method. Go doesn't have virtual methods, and the method receiver is always the exact type shown in the receiver.

If you want to write code that uses a different style, go ahead. You can also simply ignore the associated lint errors.

The current style guideline has the advantage of internal consistency: the naming convention for a parameter is the same whether or not it's the receiver. This makes sense to me, since in Go the receiver behaves no differently from other parameters.

Also for what it's worth, I've had substantial experience with both Python and C++ and I still prefer the Go style. It feels odd now to name all method receivers the same, even ones of completely unrelated types.

In bigger projects involving many developers, I find readability much more important than "this has a special meaning in other languages" (who cares about other languages) and "internal consistency" arguments. We read code 10x more often than we write code, and it is important to quickly know what an identifier represents.

this/self enables a reader to quickly know that the identifier is the receiver.

I don't see why naming the receiver this or self would be of such importance that it warrants a section of its own in the idiomatic golang style guide.

We've been writing Go code for a decade with a convention of not using this or self as the receiver name. That's simply not going to change at this point.