Isn't item (3) more of a policy thing rather than a language thing? Granted, I actually never coded in Kotlin (and very very little in Go), so if it's "encouraged" in Kotlin, then your point (3) makes sense.
This is actually one of our reasons for choosing Go! We recognized that we'd have to come up with a fairly detailed style guide for Kotlin to reflect how we wanted to generally approach things so that it's possible to jump into another part of the codebase and not get lost.
I've worked with systems where some of the things were defined as a DSL within Kotlin (with implicit receivers and a shitton of extension functions), so you can definitely shoot yourself in the foot.
I think it's ameliorated by being designed by an IDE developer, so all that magic has control+click to go to definition. I've debugged some hairy nested implicit receiver code with jetpack compose pointer events, and found it very easy to read exactly what was executed.
I'm a beginner though, and kotlin was the first language where it occurred to me I could just read the source of a library.