I've been working with Cocoa for 20 years, back from the NeXT days. I certainly see where Swift is going, and there's a possibility that it will surpass Objective-C in the future, but for the time being they will live together in relative peace.
Objective-C provides a number of patterns that aren't available in Swift due to the dynamic nature. For example, transparent network proxies are possible in Objective-C using message forwarding techniques. Similarly, it's possible to swizzle method implementations under the covers so that a replacement mechanism can be called instead. These don't sound like much but they are used to implement some powerful mechanisms, like the observable patterns and key value binding that is built upon it.
Swift is really a much better C++ than a better Objective-C. The language is terser and the underlying compilation mechanism can perform more optimisations than C++ (or Objective-C!) can. For example, Swift has the concept of a module (aka framework) and the Swift compilation can provide module-visible functions that can be called between different classes but still be optimised at the module level (e.g. in-lined).
There are a lot of compromises in the language at present; it can fallback to generate an Objective-C class which then means that the Swift optimisations aren't effective; and when data is passed from one layer to another it may have different performance characteristics (a built-in Dictionary will perform differently than an equivalent NSDictionary, even if they can be used in the same way).
A lot of the problems stem from the fact that Objective-C has grown over time, and itself has had new mechanisms added. Blocks were only added relatively recently, and so some APIs have support for callbacks with blocks, whilst older APIs don't have block support. Those that do support blocks work particularly well with Swift, because you can have a trailing lambda(closure) and pass that in as a block; if it doesn't then it involves writing a separate Swift/NSObject class that implements a callback interface, which increases the size of the codebase.
I would imagine that Apple will focus on the important things - like fixing the compiler/xcode bugs (they've got a lot of work to do there still) and introducing newer features/fixes (class members can't be that hard...) before there's an exhaustive overview of the APIs. That said, I think the existing APIs will largely do their own things (being looked after by different teams), perhaps adopting blocks where they are not yet present, but there would have to be a big shift away from things like UIKit in order to make a change.
Close observers will note the UI layer is already being abstracted with CoreGraphics (a C library) and Metal (a lower layer C library) so it's not too much of a stretch to imagine a new UI layer written in Swift -- but Apple will keep that under wraps for a long time until it is baked.
Disclaimer: I published Swift Essentials (http://swiftessentials.org) and expect Swift to only grow from here, even though Objective-C was my first love.