I am an iOS developer and I haven't used ObjC in over five years. There probably isn't any reason to start a new app or library with anything other than Swift. So it's just going to depend on the legacy code base.
I agree there's no good reason to write new (iOS) stuff in ObjC now days, but you're likely to still encounter plenty of ObjC if you're maintaining old projects.
Interoperability between Swift and ObjC works really well for the most part, so I tend to write any new files/modules in Swift, and older apps end up being a hybrid of both. I rarely see justification in rewriting existing ObjC code in Swift unless the code needs a rewrite anyway.
Since Swift UI is iOS-first, when the apps get ported to MacOS, they bring a lot of mobile-isms: the views and animations are often wrong, the controls are often wrong (like even the Apple's own settings app breaks a lot of established platform conventions and Apple's own HIGs), integration with system services is often incomplete (like proper keyboard shortcuts, I can't set a shortcut for Conversations->Delete in Messages anymore) etc.
Because of that I've seen people discuss that they have to reach for AppKit and/or ditch SwiftUI and got all in with AppKit, and that is easier to do from Obj-C.
Also AppKit works perfectly well in swift. People just probably remember the ObjC versions of things better since that’s where this all started. But the naming is pretty standard if you remember the old calls.
Interoperability between Swift and ObjC works really well for the most part, so I tend to write any new files/modules in Swift, and older apps end up being a hybrid of both. I rarely see justification in rewriting existing ObjC code in Swift unless the code needs a rewrite anyway.