They should have made use of JVM bytecodes that allow to optimize lambdas away and make JIT aware of them, via invokedynamic and MethodHandle optimizations.
Naturally they cannot rely on them being there, because Kotlin also needs to target ART, JS runtimes, WebAssembly and its own native version.
Even then, they benchmarked it, and inlining was still faster* than invokedynamic and friends, so they aren't changing it now JVM 1.8+ is a requirement.
* at the expense of expanded bytecode size
Naturally it is a requirement, JetBrains and Google only care about the JVM as means to launch their Kotlin platform, pity that they aren't into making a KVM to show Kotlin greatness.
If it feels salty, I would have appreciated if Android team was honest about Java vs Kotlin, but they weren't and still aren't.
If they were, both languages would be supported and compete on merit, instead of sniffling one to push their own horse.
Even on their Podcast they reveal complete lack of knowledge where Java stands.
PS Yes, I know, there is some weird way to disable it. Somehow that way changes every version and is about as non-intuitive as possible. And trying to actually support the encapsulation is by a wide margin more work than it is worth.
Second, modules' encapsulation is not what caused the migration difficulties from 8 to 9+, evidenced by the fact that it wasn't even turned on until JDK 16: https://openjdk.org/jeps/396. From JDK 9 through 15, all access remained the same as it was in 8. The reason a lot of stuff broke was the JDK 9 was the largest release ever, and it began changing internals after some years of stagnation. Many JDK 8 libraries had used those internals and had become dependent on them not changing - though there was no promise of backward compatibility - because there was no encapsulation.
Finally, the market clearly wants things like projects Loom and Panama and Valhalla, things that wouldn't have been possible without encapsulation (at least not without breaking programs that depend on internals over and over). It's like people complaining about the noise and dust that installing cable ducts causes and say, "nobody asked for this, we just asked for fast internet!"
On the other hand, Android doesn't even support Java 8. It supports the long-dead Java 7 plus a subset of Java 8 features. Android essentially froze their core application runtime in amber over ten years ago and have just been adding layer upon layer of compiler-level sugar ever since. The effect is an increasing loss of the benefit of being on the Java platform, in terms of code sharing.
Maybe Google could finally support latest Java versions on Android, instead of begrudgingly update when Kotlin lags behind Maven Central most used versions.
Which by the way is a Java 17 subset, not Java 8, when supporting Android versions below Android 12 isn't required.
Also not all Kotlin inlines are lambdas or even include method calls
And not all macros, but just the ones which expand to massive expressions
Think template expressions in C++ or proc macros in Rust
In general it's a performance benefit and I never heard of performance problems like this. I wonder if combined with Scala's infamous macro system and libraries like quicklens it can generate huge expressions which create this problem.