Ну, ИМХО имеет, хоть и достаточно косвенную. Гугл начал продвигать котлин в +/- 2017 году как замену Java, по моему скромному мнению только из за этих судов с Oracle (гугл тогда проигрывал).
Java в Android убрать невозможно вне зависимости от того, выиграл бы Google или проиграл. Тут речь бы шла лишь о сумме выплат Oracle в случае поражения. А так - Java это основа Android и никуда она не денется ни при каких обстоятельствах, слишком много кода на ней написано.
Ну и, поскольку Kotlin был объявлен предпочитаемым языком для Android, переигрывать это смысла нет никакого опять же вне зависимости от решения суда. Во-первых это не понравится программистам, которые потратили кучу времени на изучение Kotlin, во-вторых Kotlin в любом случае лучше Java, в-третьих Google уже вложился в интеграцию Kotlin в Android, в-четвёртых Jetbrains идёт навстречу Google во всех вопросах, например для развития языка создана отдельная компания, в которую вроде и от Google вошли представители.
Будущее развитие Java во многом определяется развитием JVM. Например value types для оптимального представления некоторых объектов в памяти, project loom для реализации легковесных потоков. Но у Android вообще другая архитектура использования Java, к которой всё это развитие не имеет никакого отношения. У них свой байткод, у них свой подход с AOT-компиляцией, у них свои сборщики мусора, они вообще никак не используют HotSpot JVM. Это всё даже Java называть нельзя в строгом смысла этого слова, это Java-подобная среда выполнения, не более. Это я к тому, что Java как таковая не представляет большой ценности для Android. Максимум, что они могут заимствовать из будущих версий, это какие-то мелкие синтаксические улучшения вроде records, пока они будут как-то ложиться на виртуальную машину Android.
А вот с Kotlin всё немножко по-другому. Там можно прикручивать и компиляцию напрямую в Dalvik bytecode, и какие-то оптимизации/улучшения проводить параллельно и в Kotlin и в Dalvik. Т.е. в любом случае это более удобный вариант для Google в перспективе. Но, конечно, при любом стечении обстоятельств поддержка Java никуда не денется.
А вот у меня противоположный опыт. Последние два банковских проекта разрабатывали именно на котлине. Сейчас занимаюсь техлидством на финтех стартапе, тут с командой разработчиков единогласно приняли решение взять котлин как основной язык разработки.
Касаемо скорости разработки тут вопрос состоит в основном вот в чем. 95% тех кто пробуют котлин воспринимают его как ситаксический сахар к джаве, в то время как это совершенно другой язык. Если применять его на полную, с расширениями, компаньенами, дата классами, то уменьшение объема кода составляет до 3-5 раз относительно идентичного кода на джаве. И соотвественно возрастает и скорость разработки.
Со скалой я работал полтора года, на мой взгляд язык имеет очень сильный оттенок академических идей и фп эзотерики. Из-за этого имеет очень высокий порог входа. А так же в ним имеют место ранние реализации идей вроде расширений. Сравните расширения в котлине и в скале и сразу все станет очевидно. Котлин вырос из скалы как более совршенный и более пригодный для промышленной разработки язык.
А если сравнивать фп прикладного уровня скалы и котлина, то разницы я никакой особенной не вижу. Во всяком случае но уровне прикладной разработки я ее не обнаруживаю.
А вообще ситуация с джавой в проме выглядит довольно забавно. Сейчас уже 16 версия вышла, а в реальной разработке крутится до сих пор 8 версия. Я всего один раз на крупном проекте видел где применяли 11 версию и то это был небольшой логистически подпроект. В остальном требования весгда установлены рестриктивно - все что производится вутри компании должно работать с jre8. И вот на фоне таких претиснений, котлин и скала довольно хорошо пошли в ход. Те же самые банки приняли политику - либо пишите на 8 джаве, либо выбирайте любой java next язык которые может быть собран с восьмым рантаймом. Консревативные разработчики с седыми бородами продолжают писать на джаве. А те кто помоложе, кому ближе современные концепции разработки, берут либо скалу либо котлин.
потому что серверное применение это тонны java инфраструктуры, привязанной к стандартной java 1.8, где все котлиновские финтифлишки не нужны. посему котлин там идёт как немного улучшенная жава и соответственно никаких ускорений разработки нэт и быть не могёт. в телефонах совсем-совсем другая история и там котлин будет (если уже не) номер один для разработки, потому что тупо позволяет гуглу экономить тонну денег.