Using autocompletion means you don't have to leave the editor window and I've found it hugely useful for methods which have several overrides - instead of leaving the editor, you just choose the one you need as you type.
At some point I read through the Kotlin docs and found it interesting, but didn't have any projects in mind for it. I might try my hand again along with IntelliJ / Android Studio.
I've happily used other JetBrain products such as RubyMine and WebStorm.
I don't think it's the built-in constructs which are hard to find. In JVM-land, it's sifting through often verbose library interfaces that makes discoverability a huge win. Looking in Javadoc for that single function to convert from Type A to Type B properly can be a real pain.
But even then it's far more discoverable / less overwhelming than "I have a String. I want a Uri. Do I use a UriBuilder, UriParser, Uri, StringConverterFactory, etc?". Not only do you have all classes to choose from, you need to pick the one with the right methods (usually not visible when choosing the class) for the data you have.
Some IDEs can and do improve the helper-classes case a bit by letting you type e.g. `myString.uri` and showing you "uri" methods both on string and static methods anywhere which accept strings... but it's not widespread, sometimes unhelpful (there are far too many "parse" methods), and you're still missing out on the class context which sometimes has important info.
As long as you have good docs, I find discoverability is rarely an issue. One of the first things I do when picking up a language is look through its built-in constructs, to familiarize myself with the available options.