I'm not sure that's the whole story. Kotlin was blessed on Android because it was growing like a weed, developers didn't need Google's permission to use it and weren't asking for it. The Android team went with the flow (smartly).

I evaluated Ceylon vs Kotlin in 2015, back when Kotlin wasn't even close to a 1.0 release and neither had any adoption. They're very similar in a lot of ways and so the choice came down to a lot of small things added up rather than any one big thing. I chose Kotlin for a lot of reasons, but a few (in no particular order) were:

1. It had a more convenient syntax. The Ceylon designer felt that autocomplete meant verbose syntax didn't matter but it does. "variable Integer foo = 10" isn't just a typing issue but also a reading issue. "var foo = 10" is better.

2. Ceylon deviated more from the JVM ecosystem than Kotlin, in particular, it invented its own collections like Scala, but which didn't appear to be much different to regular Java collections. This means idiomatic Ceylon would obviously be a Ceylon library to users and not a Java library. Kotlin uses standard Java collections but enhanced via extension methods. It also provides a bunch of knobs to make the output classes seem like idiomatic Java classes in the few places that doesn't happen automatically, so you can reasonably use it for libraries. This makes a huge difference to Java interop. Kotlin is really the only JVM language that takes Java interop seriously: the rest all treat it as a price of admission to use the JVM at all and minimise their effort on it.

3. Ceylon was mostly tooled for Eclipse which, in my view, is an inferior IDE to IntelliJ. The tooling was itself not as good as even the pre-1.0 Kotlin plugin.

4. Ceylon had invested heavily in a complicated module and type system, which was the primary set of things they emphasised. These sorts of features have a relatively poor track record of delivering value; slightly-stronger-than-Java seems to be about the sweet spot at the moment. Much stronger than that and you end up in Haskell. Kotlin went in for more type inference and more usable generics (convenience), Ceylon

5. Ceylon seemed much riskier to me (correctly). Nothing used it. It was clearly the project of one guy at Red Hat who'd had a previous successful project (Hibernate), but Red Hat weren't talking about it or using it in any way. On the other hand JetBrains had a large team assigned to Kotlin and were explicit that they were creating it to use in IntelliJ itself. The existence of a Java to Kotlin converter tool showed that they were completely serious about this, as J2K was a lot of work to build and would only be useful in a truly serious assault on existing Java codebases. Ceylon seemed far more interested in fancy type systems than the practical details of adoption.

6. Ceylon had some weird gotchas and interop glitches that weren't normal for Java-like languages, like a sensitivity to the case of the first letter of identifiers (I know Go does this too) and difficulty handling Java arrays. There are named constructors (cool) which don't compile to static methods as is idiomatic for Java but some weird Ceylon specific notation (boo). This sort of thing showed it wasn't trying to be "just a better Java" which is what I was in the market for.