So many things to unpack there:
- Their thoughts on reactive programming show a large gap in knowledge. All of Android is reactive programming since everything is callback and lifecycle-based and yes it can cause leaks. Android has forced reactive programming to be the only viable solution because of it's lifecycle and callbacks models and thus forced leaks on itself. Whether you choose to deal with it manually, with coroutines, with Rx, or with something else is irrelevant. Those are just higher-level abstractions. You cannot write an Android app without reactive programming principles since nearly everything on the system is asynchronous. I suspect they're just an RxJava hater.
- Kotlin was definitely supported primarily for third-party applications. Google's first-party apps are generally irrelevant since they use a bespoke build system and bespoke suite of libraries unlike how normal apps are developed. I know a lot of people like to base decisions on whether Google uses things, but they represent 0.01% of the Android developer ecosystem and so they contribute 0.01% to decisions made. I would recommend ignoring them. That being said, there's already first-party apps using Kotlin and work is being done to support more. The Bazel team is developing Kotlin rules in the open on GitHub if you're interested. I suspect they're just a Kotlin-hater.
- AOSP is big so "Kotlin support in AOSP" is ill-defined. Support for Kotlin was added to the (yet another bespoke) build system of AOSP a year ago. I don't know if any packages are using it or not. It's definitely being used in some of the tooling. And of course, the AndroidX libraries are developed in AOSP and they have a ton of Kotlin in them. If you're talking about the framework, it doesn't really make sense to put Kotlin in the framework as it would lock the standard library to that version and we would have the same problem we do with other platform APIs. And if you jarjar it out of the public package, then what advantage are you bringing?