I'm a bit opinionated here and I know some people will disagree. But being a grey beard myself (50), I don't disagree with your sentiment here. People tend to get stuck in their ways as they get older. And I've observed a lot of people my age resisting anything new (languages, frameworks, anything that's newer than what they learned 20 years ago.

Working with younger people exposes that quite mercilessly and I can recommend doing that if you catch yourself doing a lot of repetitive projects with people well over 40. Try something new if you want to stay relevant. Move on if your colleagues can't deal with that. It's only going to get worse with them.

I've been using Kotlin with Spring boot for backend development since 2018. I did Java before that; since 1995. Java has indeed improved and was probably nudged along by what Kotlin and Scala and other languages have done. But it hasn't really caught up properly IMHO. Everything Kotlin does right out of the box (intentionally, to fix what Java did wrong here), Java continues to do wrong out of the box and this is actually a big deal because it does a lot of important stuff wrong mainly for compatibility reasons. That's the big biggest difference. These are things that Java cannot fix in a backwards compatible way. That alone is a good reason to switch.

Examples of this are that it makes code less null safe, non final, introduces unnecessary mutable state, etc. Kotlin allows you to do these things when you need to but it defaults to things being closed, final, val (instead of var), etc. And these are just things that Kotlin has been doing right since it's first releases. It has progressed a lot since then.

If you like verbosity and don't want access to the countless convenient extension functions, DSLs, co-routine support, etc. that e.g. Spring ships for Kotlin, go for Java. In they end you kind of do the same things. But IMHO in a needlessly verbose and clumsy way.

But you are missing out. IMHO anything to do with Spring Flux is just an order of magnitude easier via Kotlin and co-routines and IMHO even attempting to use that from Java is misguided. But in Kotlin, you can hardly tell the difference with non reactive code. With Java, this turns into a mess of leaky abstractions, function chaining, and lots of boiler plate. Our server is effectively using only a handful of threads with lots of websockets, connections, background processing etc. happening.

Reactive/async stuff across all of the mainstream Java server frameworks is well supported from Kotlin and has been for many years. E.g. the co-routines library ships with lots of extension functions for just about anything you can name. The green thread stuff Java does is often cited as a thing that closes the gap. But from a Kotlin point of view it's just something that makes using legacy Java code a bit less tedious.

Jetbrains and Spring did some joint announcements at the latest Kotlin conf. The upcoming major release of Spring Boot is going to be even more Kotlin heavy and centered than the current one is. And honestly, you had a superior experience with v1 way back even. They won't abandon Java support. But at this point, you are really missing out if you are sticking with Java. There are non technical reasons for doing that but very few (if any) technical reasons.

They are doing a big push with the new release on making nullability checks on all the Spring Java stuff stricter for Kotlin and making sure Kotlin does the right things. And all their documentation was already dual Kotlin/Java but looks like it might be leaning towards Kotlin first going forward.

Many reasons to like Kotlin. If somebody tells you it's Android only that was never true and there's a lot of quiet Kotlin usage with anything Java because there's not a single Java framework that you can't seamlessly use from Kotlin. And almost universally it's a better experience. The older the better actually. Because the old one tend to not use any of the new Java features. Where new is introduced in the last 15 or so years.

I think the Spring support is not highlighted enough. It is very good, among other things OpenAPI client code generation is very good out of the box.