I think that's an absolutely reasonable reaction. I can only say that, as someone that primarily works on Android, I'll of course prefer Compose UI since it's technically the "native" solution for me already. And while reading further, keep in mind that my views are going to be biased towards Kotlin and such for that reason, of course. There's also the additional disclaimer that it's still relatively early days, and the developer experience isn't perfect out of the box with every platform, just yet.
By opting for Kotlin and Compose UI, in addition to being a first-class citizen on Android, I gain the ability to share code with many other platforms to any degree I need. That is, just the app logic can be done in Kotlin while keeping the actual UI in whatever each platform prefers (UIKit on Apple platforms, Swing on JVM, etc.), or it can be entirely done with Compose UI (which usually means being rendered via something like Skia). And even if you adopt Compose UI, there are different degrees to which that can be applied; Compose UI can output either DOM elements or render to a canvas for the Web target, for example. (It's actually curious you mentioned Qt. As a day-to-day KDE user, I'm interested in playing around with the possibility of wrapping Qt components with Kotlin/Compose as well.)
No matter what degree of that I choose, it's still going to be more "native" than something like RN. Depending on the target platform, Kotlin will compile down to JVM/Dalvik bytecode, LLVM bitcode/machine code, JavaScript, WASM, etc. RN (last I checked, at least) still relies on running in a JavaScript engine at the end of the day. Flutter will get you closer than RN, but it's still not quite native to any one platform in particular and you're still introducing Dart as another language you need to know. A .NET-based solution suffers a similar problem, and IMO it feels even more out of place on Linux than the rest.
(To be clear, Compose UI has been able to learn a lot from Flutter, as they both originated at Google and both take a declarative UI approach; I largely consider Compose UI to be Flutter's successor.)
Ultimately, it can boil down to this: if you want to support multiple platforms, you need expertise in each. Adding most traditional cross-platform frameworks such as Flutter or RN also means you need expertise in that framework as well. In the worst case, my expertise with Compose UI will remain good for the work I need to do on Android. The worst case for most of these other frameworks is that it becomes irrelevant and you need to learn something else anyway.