I learned SpringBoot before joining a team that primarily works with Grails using Groovy. I never tried using Kotlin with Grails myself.
In my opinion, Groovy fits Grails well. They’re both implicit in many ways. Unlike Spring’s odd “programming with method names” here and there, Grails takes it up several notches of hidden convention and implicit association. Things gets detached from its clear meaning.
I think a lot of this user pain stems from a overuse of “convention over configuration”. In Grails, just like in Groovy and other difficult to tool languages, it’s difficult to trace a value through the framework since you need custom tools in order to see the docs or jump between bean mapping.
IntelliJ Ultimate has great tooling for both Spring and Grails to the point that almost entirely eliminates my frustrations with the framework. It’s paid. If Grails relied on less hidden conventions then you would get all the same tooling for free from the language.
Kotlin could fix most of the issues that spread through Groovy libraries in a Grails project. But personally I would prefer to use the standard directory layout (Grails makes you change that*), and use the newer Spring Kotlin support that they have been working for over the last couple years.
Grails is good in a lot of ways, it’s a powerful framework. But I’d personally choose SpringBoot over Grails even if Kotlin wasn’t in the picture. My colleagues who are the main reason we use Grails are trying to move away from Grails to Micronaut (made by the same people who did Grails).