Aquí hay algunas razones, que pueden ser más o menos convincentes para usted, según sus propias preferencias:
No lo descarte simplemente por ser "azúcar sintáctico". Si bien puede decir que algo es solo azúcar sintáctico, después de todo es el azúcar que endulza su vida, como programador y bebedor de café o té.
Singletons: cada Scala objectes inherentemente un singleton. Teniendo en cuenta que en el mundo de Java, las personas están implementando singletons de todo tipo de formas diferentes y la mayoría de las veces terminan cometiendo algún error en su implementación, no se puede cometer un error tan simple como eso en Scala. Escribir en objectlugar de hacerlo lo classconvierte en un singleton y listo.
Acceso a métodos estáticos: se puede acceder a los métodos estáticos en Java desde los objetos. Por ejemplo, suponga que tiene una clase Ccon un método estático fy un objeto cde tipo C. Entonces deberías llamar C.f, pero Java te permite (aunque con una advertencia) usar c.f, lo que cuando vienes del fondo de Scala realmente no tiene ningún sentido, porque los objetos no tienen un método frealmente.
Separación clara: en Java puede mezclar atributos y métodos estáticos y no estáticos en una clase. Si trabaja disciplinado, esto no se convierte en un problema, sin embargo, si usted (o alguien más para el caso) no lo hace, entonces termina con partes estáticas y no estáticas entrelazadas y es difícil saberlo de un vistazo rápido qué es estático y qué no. En Scala, todo lo que se encuentra dentro del objeto complementario no forma parte de los objetos de tiempo de ejecución de la clase correspondiente, sino que está disponible desde un contexto estático. Viceversa, si está escrito dentro de una clase, está disponible para instancias de esa clase, pero no desde un contexto estático. Esto se vuelve especialmente oneroso en Java, una vez que comienza a agregar bloques de inicializador estáticos y no estáticos a su clase. Esto puede llegar a ser muy difícil de comprender en términos de orden de ejecución dinámico.
Menos código: no es necesario agregar la palabra estática a todos y cada uno de los atributos o métodos de una forma object, de modo que el código sea más conciso (de hecho, no es realmente una ventaja importante).
Las desventajas son mucho más difíciles de encontrar. Se podría argumentar que las partes estáticas y no estáticas deben estar juntas, pero están separadas por el concepto Scala de objetos complementarios. Por ejemplo, puede parecer extraño tener un diagrama de clase, pero luego terminar creando dos cosas en el código y analizar qué atributo va a dónde.