I think you got all of that pretty mixed up.

- Implicit resolution can be slow, because you can make the compiler do arbitrary work for you. This is completely unrelated to implicit classes themselves.

- Scala had the option to either not ship value types at all, or support only a limited subset of things that can be made work well under the current restrictions. If Scala didn't ship value types, the JVM would have probably never gotten them. You can thank Scala developers later for dragging Java people into the 1990ies.

- Extension methods looks totally cool on paper, but are pretty much useless for writing maintainable, readable code, which also does something useful:

    Dev:    "Ok, I want to be able to use String as if it 
             was a collection of chars."
    Kotlin: "Sure, just implement all the collection methods
             one-by-one."
    Dev:    "But, but ... all implementations I need are
             already implemented in that trait over there?"
    Kotlin: "Bad luck, I guess. You could of course just
             delegate all your methods to that trait."
    Dev:    "But then I would need to create a real instance
             of that trait first which implements the missing
             abstract method ... that's more boilerplate than
             just copy-and-pasting the code?"
    Kotlin: "Yeah, you have to decide whether to write a
             short implementation on your own or pay the
             price for sharing common pieces of code."
    Dev:    "... <much later> ... ok, I now implemented all
             all the methods of the collection interface of
             my own ... I guess ... the compiler will warn me
             if I forgot to implement a method from that
             interface or messed up a signature, right?"
    Kotlin: "No."
    Dev:    "I just tried passing my String to a method
             expecting a collection ... it doesn't even
             compile?"
    Kotlin: "Just because you went to all the trouble to make
             String act like a collection doesn't mean it's
             supported as soon as abstraction enters the
             picture."
    Dev:    "So I can write cute things like myString.map(...)
             but as soon as map(...) is moved to a method,
             I have to overload that method to accept both
             Strings and collections?"
    Kotlin: "You could also just write a
             StringCollectionWrapper and wrap every String
             in that when you need it."
    Dev:    "I guess the compiler will figure out when I need
             to wrap it?"
    Kotlin: "No, you have wrap it manually every single time."
    Dev:    "So extension methods are basically just syntax
             for writing static methods in a nicer way?"
    Kotlin: "Can you please stop asking questions while I
             waste your time?"