La razón principal es probablemente que la igualdad de objetos se verifica con mucha más frecuencia que la identidad de objetos, por lo que debería ser al menos igual de fácil.

No he visto una declaración definitiva sobre esto. Pero hay un puntero en el libro Kotlin In Action , escrito por miembros del equipo de Kotlin. La Sección 4.3.1, que presenta el operador == , primero describe las comparaciones de Java y dice que:

en Java, existe la conocida práctica de llamar siempre a equals , y existe el conocido problema de olvidarse de hacerlo.

En Java, verificar la identidad del objeto es fácil:

 if (firstObj == secondObj)

Pero verificar la igualdad de objetos es más largo y bastante menos claro:

 if (firstObj.equals(secondObj))

- o más bien, si no quiere arriesgarse a una NullPointerException:

 if ((firstObj == null) ? (secondObj == null) : firstObj.equals(secondObj))

Puedes ver cuánto más doloroso es escribir y hacerlo bien. (Especialmente cuando uno de esos objetos es una expresión con efectos secundarios...)

Así que es fácil olvidar la diferencia, o no molestarse, y usar == en su lugar. (Lo que probablemente cause errores que son sutiles, difíciles de detectar y muerden de forma intermitente).

Kotlin, sin embargo, hace que la operación más común sea la más fácil: su operador == verifica la igualdad de objetos usando equals() , y también se ocupa de la verificación de valores nulos. Esto soluciona el 'problema de olvidarse de hacerlo' de Java.

(Y aunque la interoperabilidad con el código Java era claramente un objetivo principal, JetBrains no se limitó a tratar de parecerse a Java; Kotlin toma prestado de Java siempre que sea posible, pero no tiene miedo de cambiar las cosas para mejor. Puede verlo en el uso de val y var y tipos finales para las declaraciones, los diferentes valores predeterminados para el alcance y la apertura, las diferentes formas en que se maneja la varianza, etc.)

Una de las motivaciones de Kotlin fue solucionar muchos de los problemas en Java. (De hecho, la comparación de lenguajes de JetBrains comienza con una lista de 'Algunos problemas de Java abordados en Kotlin'). Por lo tanto, parece probable que esta sea una razón importante detrás del cambio.

Además de la excelente respuesta de gidds, hay otros lenguajes además de Java que influyeron fuertemente en Kotlin. En particular, Scala y C#. Una cita de Dmitry Jemerov (el enlace es a InfoWorld, que no me gusta mucho, pero esa es la mejor fuente que he encontrado):

Hemos analizado todos los lenguajes JVM existentes y ninguno de ellos satisface nuestras necesidades. Scala tiene las características correctas, pero su deficiencia más obvia es una compilación muy lenta.

Claramente, == fue una de esas características que sintieron que Scala acertó, porque funciona exactamente igual (hasta el nombre de igualdad de referencia, que es eq en Scala).

Y puede encontrar una explicación para el diseño de Scala en el libro Programación en Scala, que tiene a Martin Odersky como uno de los autores:

Como se mencionó en la Sección 11.2, la definición de igualdad es diferente en Scala y Java. Java tiene dos comparaciones de igualdad: el operador ==, que es la igualdad natural para los tipos de valor y la identidad del objeto para los tipos de referencia, y el método equals, que es la igualdad canónica (definida por el usuario) para los tipos de referencia. Esta convención es problemática, porque el símbolo más natural, ==, no siempre corresponde a la noción natural de igualdad. Al programar en Java, un escollo común para los principiantes es comparar objetos con == cuando deberían haber sido comparados con iguales. Por ejemplo, comparar dos cadenas x e y usando "x == y" podría dar falso en Java, incluso si x e y tienen exactamente los mismos caracteres en el mismo orden.

Scala también tiene un método de igualdad que significa identidad de objeto, pero no se usa mucho. Ese tipo de igualdad, escrita "x eq y", es cierta si x e y hacen referencia al mismo objeto. La igualdad == está reservada en Scala para la igualdad "natural" de cada tipo. Para los tipos de valores, == es una comparación de valores, como en Java. Para los tipos de referencia, == es lo mismo que equals en Scala. Puede redefinir el comportamiento de == para tipos nuevos anulando el método equals, que siempre se hereda de la clase Any...

Por otro lado, C# permitía la sobrecarga == por separado de Equals , y terminaron con uno de los diseñadores de lenguaje diciendo

La respuesta larga es que todo es raro y ninguno funciona como debería.