It would be impossible to evolve Obj-C to add most of Swift's capabilities unless you drop binary and source back compatibility. At that point it's just another new language and you've lost the things you say made Obj-C simpler.
I have a hard time believing any engineer is productivity bound by Swift's build times and especially indexing times, since indexing doesn't affect your ability actually write code. Typically developer productivity is bound by thinking of an appropriate solution to a problem and expressing that solution in a language. Given how much easier that expression is in Swift, especially if you spend a bit of time optimizing the language to your problem, the build time becomes rather incidental. Add to that Swift's ability to catch far more issues at build time and its language features and the Obj-C solution falls further and further behind. Even if your Obj-C solution builds faster it will likely be an inferior solution anyway.
I see you haven't worked in a swift code base that is more than a few engineers. Work in a project that is 20-80+ engineers and you slam into these issues very quickly. Last time I checked the inflection point starts around 100k lines of code.
Also 'thinking' of solutions often involves writing something and then trying it out in a build-edit-run cycle, and then integrating your thing into a larger app context, which also involves many build-edit-run cycles. Most people do not think of their solution in whole cloth in their head other than in a broad strokes manner and then start writing code. This means indexing and building matters greatly for actual productivity.
Indexing issues means your ide is not auto completing, click to definition doesn't work, and in the past, even syntax highlighting failed. Also when you have some half formed code, a lot of indexing functions start breaking in an annoying way, while I don't really recall this behavior in Objective-C code bases.
In practice I've found swift being 'able to catch issues more' is mostly strict nullability, better array / dictionary strictness and enums, which would actually be relatively simple to implement in an extended ObjectiveSwift. Strict generics would be more work, but you can add it to the language also as a version update. Dart showed how it's possible to add big changes like strict nullability to a language with their dart v1 -> v2 update. Objective-C could have gone down that path instead.
> Last time I checked the inflection point starts around 100k lines of code.
if your using swiftui + generics for your view models, depending on what your doing, be prepared to hit that limit at around 2000 lines, and then your app wont even compile...
I have a hard time believing any engineer is productivity bound by Swift's build times and especially indexing times, since indexing doesn't affect your ability actually write code. Typically developer productivity is bound by thinking of an appropriate solution to a problem and expressing that solution in a language. Given how much easier that expression is in Swift, especially if you spend a bit of time optimizing the language to your problem, the build time becomes rather incidental. Add to that Swift's ability to catch far more issues at build time and its language features and the Obj-C solution falls further and further behind. Even if your Obj-C solution builds faster it will likely be an inferior solution anyway.