Release branches are fine (mobile apps, sure... web apps, probably not). Again, context is key.
You can still integrate to trunk as one would expect in TBD, no need for the delayed integration in Gitflow.
A common practice I see with mobile teams is they will create a 'release/x.y' branch sourced from trunk as part of their release routine (at some regular cadence, like 2-weeks).
If they need to (surgically) apply a hotfix, they can apply it to the release branch. Since the app store review process makes deploying immediate fixes impossible, a stronger emphasis on staging/RC QA is good as well.
"Trunk-based development" is essentially counter-marketing to Gitflow. Before Gitflow, trunk-based development was so routine it didn't need a proper name or website.
Gitflow has the "interesting" properties of being more complex than release-ready trunk-based setups, while (in most contexts) decreasing quality, and delivery speed.
Unfortunately, Gitflow is very appealing to mediocre managers who want to point to a website and some pretty pictures and say "we do that" (thus, alleviating themselves of any actual engineering or contextual thinking). So the counter-marketing is helpful, but it feels rather ridiculous how the software world is so susceptible to these trends.
It reminds me of the Alan Kay quote, "programming is a pop culture."
Presumably they could have the dx tool in the current toolchain support Java 8 bytecode .class files as input (just as the Jill linker in Jack toolchain allows).
>I thought the whole rationale for Jack was it was a clean break from Sun / Oracle Java and entirely open source.
In the current toolchain you do something like the following: java sources -> javac -> .class files -> dx tool -> dex file -> ...
(We already have an open javac with OpenJDK by the way, and dx is part of AOSP, so "entirely open source" was essentially solved).
Part of the idea behind Jack was that by creating a new compiler toolchain specifically for Android you could have a faster build by jettisoning the unnecessary .class intermediates and going straight to dex from the sources (or rather, as it turns out, a pre-dex that goes into a new intermediate .jack file with other metadata).
>The possibility of running Scala >=2.12 (or any other language that is committed to Java 8[1]) on Android seems even more remote now
To quote the article: "We've decided to add support for Java 8 language features directly into the current javac and dx set of tools."
The way I'm reading that could (maybe) work, the regular toolchain (javac -> .class files -> dx -> dex file) would get an upgraded dx tool that could take classes with Java 8 bytecode as input. In that case something like Scala (or any compiler that outputs Java 8 bytecode classes) would be just as well supported.