Creo que el razonamiento es generalmente el siguiente:

• Los métodos abstractos son marcadores de posición que se supone que debe implementar una subclase concreta.

• La clase base abstracta tendrá un método concreto que utiliza este marcador de posición abstracto y, por lo tanto, requiere que se implemente; sin esto, los métodos abstractos tienen poco sentido. P.ej:

   abstract class Foo { bar() { return this.baz() + 1; } abstract baz(): int; }

• Esto solo se puede llamar en una instancia concreta, por ejemplo:

   function (foo: Foo) { let val = foo.bar(); ... }

  El resultado será diferente aquí según la subclase concreta de Foo que obtenga, pero está garantizado que todo funcionará.

Ahora, ¿cómo se vería esto con métodos static ?

 abstract class Foo { static bar() { return this.baz() + 1; } abstract static baz(): int; } function (F: typeof Foo) { let val = F.bar(); ... }

Esto parece algo lógico y debería funcionar, ¿no? Pero:

• Si escribe esto, básicamente no hay diferencia para pasar instancias de clases, excepto por el tipo typeof de escribir. ¿Entonces por qué?
• Si nunca crea una instancia de la clase, ¿cuál es el punto de una clase?
• Si su método static crea una instancia de un objeto, si actúa como un constructor alternativo , lo cual es completamente legítimo, entonces llame a F.bar() para obtener una nueva instancia, esperaría obtener una instancia de F , pero podría ser obtener una instancia de alguna subclase de la misma. Y eso podría decirse que no es deseado.

Para reformular la cadena de argumentos aquí:

• Si va a utilizar métodos static , deberían actuar como constructores alternativos y devolver una instancia, de lo contrario, tienen poco negocio como parte de la clase.
• Los constructores alternativos deberían devolver una instancia de la clase a la que los llamaste. Llamar F.bar() y no obtener una instancia de exactamente F es... ¿raro?
• Si va a llamar a constructores alternativos estáticos en clases, querrá llamarlos en clases específicas y no en variables como se muestra arriba, porque de lo contrario realmente no sabrá lo que está obteniendo (vea el punto anterior) .
• Por lo tanto, no hay un caso de uso real para un método abstract static , ya sea como constructor alternativo directo o como función de ayuda para uno, ya que eso conduciría a una violación de uno de los puntos anteriores de una forma u otra.

Por lo que veo, este es más o menos el pensamiento clásico que lleva a que los métodos abstract static no sean una cosa. Ciertas limitaciones técnicas en Java pueden haber contribuido a eso y/o conducir a dichas limitaciones técnicas en primer lugar.

En Javascript se puede argumentar que esto tiene menos sentido, ya que incluso las clases son objetos y sería completamente factible usarlos como se describe anteriormente, y en ciertas situaciones incluso puede tener sentido. Pero aquí estamos.