Indeed. Consistency - this is the key argument.
In a class’s methods, access via the this reference is so common that it is made implicit, by a longstanding convention is the Scala/C#/Java language lineage.
The purpose of extension methods is to permit retroactive extension of a class defined elsewhere. For many reasons, this is a common problem programmers face; has been for decades, and it is not going away.
There may be few such retroactive extensions, or there may be many. If Scala’s BigDecimal were implemented via extension methods instead of wrappers, as Martin has stated would have been the preferable approach if the technology were available back then, extensions would number about 100.
IMO there’s no particularly convincing reason why referring to this in a retroactive method should be explicit, but in an instance method, it is implicit. The language is more regular and consistent if the two cases work the same, and thus retroactive extension isn’t (yet again) a second-class citizen.
That said, we could not simply change the language semantics in this regard, as it would change the meaning of existing code. That’s why allowing an opt-in via import is a viable path forward.
If import at the extension-block is not possible, then my alternative syntax proposal deserves more serious consideration.