The notion of Kotlin being a mobile only thing emerged out of the happy accident that the need to get rid of Java was simply felt so deeply in Android that developers were all over Kotlin even before it was released properly. Backend developers waited a bit longer.
As a drop in replacement for Java it made a lot of sense there. Google at the time had the whole platform stuck on Java 1.6 while they were engaging with Oracle in the courts. So a lot of the nice stuff in 1.7 an d 1.8 was not usable and forget about all the stuff that was added to Java and still is being added. Most of that you could get with Kotlin right then and there. So, people jumped on it.
For the same reason, people have been using Kotlin with Spring since about the same time. Google and Spring made it official around the same time as well with Google outright labeling it as the preferred language for Android (while not cutting off Java) and Spring just adding an enormous amount of Kotlin specific features and extensions starting with Spring 5 and Spring Boot 2. At this point both have documentation for both Java and Kotlin. There are really no downsides to using Kotlin on the server. You can do everything you could do with Java and you gain access to a lot of easier to use stuff than the Java equivalent.
I've been using it since before Spring supported any of Kotlin. Worked fine then and it only got better since. The language alone is worth switching and once Spring started actively supporting it, it only got better. I write asynchronous co-routine code with Spring by default. Mostly it just looks exactly like synchronous code. The only way you can tell is that my controller functions are suspend functions. Spring takes care of the rest. That makes everything easier: more readable logic, error handling, etc.