Okay, we already have an accepted answer, but let me add a few thoughts on this as well.

First of all, it's important to understand that most features in any tool or technology are introduced to solve existing challenges. This includes everything from design changes to improvements in problem-solving.

But why version catalogs?

Well, when working on projects loaded with dependencies, keeping everything healthy and consistent is a real challenge. For example, imagine a project with multiple modules—say, 3 to 10—where each one uses a different set of dependencies. Some modules might even use the same dependency, but with different versions or from different repositories. Managing this mess and keeping everything up to date can quickly become a nightmare!

Having a centralized approach to manage all these artifact references and version strings in one place is like achieving peace on earth. I say this with confidence because I’ve faced many issues while working on large, real-world projects packed with dependencies.

And that’s it—in practical terms, version catalogs help us tackle this exact problem.

Of course, for simple projects that use very few dependencies—or for quick prototypes or throwaway projects—there’s no need to worry about using version catalogs. Sometimes we create projects just to test something, and maybe they don't even have any extra dependencies or plugins. In those cases, it’s totally fine not to use a catalog.

But as your project grows, you should really consider migrating your dependency strings to a catalog.

Also, remember that Gradle is used to build environments beyond Android. Kotlin and even C++ are well-supported by Gradle!