Not necessarily: Swift is just a really nice, efficient, and memory-safe language that works at all levels of the stack, from embedded devices and servers, to desktop and mobile applications. Swift is at home in environments where garbage collection isn't viable or desired, and can potentially run with a very minimal runtime library dependency.
That being said, a very obvious use case here is to be able to share code between your Android and iOS apps. I've written about this on the Skip blog: Native Swift on Android, Part 3: Sharing a Swift Model Layer | Skip. In this sense, Swift would be taking the place of KMP as a shared business logic layer for the application.
Swift could also be used to build the entire application, which I've written about at Fully Native Cross-Platform Swift Apps | Skip. This scenario would be more comparable to Compose Multiplatform (CMP), since the entire app stack is created using Swift, but with platform-native user interfaces (i.e., SwiftUI and Jetpack Compose) for each device.
How much or how little you use Swift in your Android application will vary based on your project's needs. You could also simply use it as a "better C++" for portable low-level logic. Since the Swift Android SDK is based on Android's NDK, it fits together with any other native code you may be using in your Android app.