"just meant that developers are expected to bundle their own thin custom-built JREs alongside the application" can be significant initial setup work and overhead, and seemed more so back then. With Java 8, I shipped a combo Swing/JavaFX application, and built it once, and it ran everywhere. Now I have to figure out the module system and figure out how to ship it with platform-specific JREs? That's a lot more packaging overhead for a hobbyist project, or at least, that's what it felt like at the time.

After hearing (from Oracle) in the early 2010s about how JavaFX was the future of GUIs in Java, I can identify with the feeling of betrayal when it was unceremoniously removed from the JDK. If I'd known that was coming, I wouldn't have added JavaFX to my Swing application.

Nowadays we know that there are Bellsoft and Azul (is ZuluFX still a thing?) JVMs that still ship with JavaFX, but when Oracle made that announcement, we didn't know that, There were a couple years there where it looked like a significant refactor to externally linking OpenJFX, and shipping one-distro-per-system instead of one JAR, would be needed to move past Java 8. Now it's not so bad, I still target Java 8 as a minimum, but can point my program's users to the Liberica JDK and everything just runs.