So, I'm deeply involved in Swift, in the sense that: I write the odd compiler feature.
From my vantage point it seems to be the opposite of your analysis. While it is true that ObjC's dynamism has all kinds of problems we want to avoid, we're also running into lots of cases where the obvious solution is dynamism, and the other solutions aren't obvious.
One concrete example I can offer you is NSCoding, which is being reimplemented right now in corelibs-Foundation. That API pretty much needs a way to look up classes at runtime, (there's really no other sane way to provide the feature). You could argue that we don't need NSCoding (in fact that was argued), but ultimately, we decided we needed NSCoding more than not. So Swift 3 adds a `_typeByName` API which does dynamic lookups of classes by string. It landed, it exists, the ship has sailed.
Another concrete example that may be interesting is XCTest. The way XCTest works is your unit tests are written as functions on a class, and we "discover" the tests by enumerating the functions at runtime. But oops, Swift has no way to enumerate functions at runtime, so we can't find any of your tests. The solution to this problem is actually pretty interesting: the latest proposal is to do sourcecode analysis from the compiler to enumerate your test functions, dump that somewhere, and then generate a second program that uses the dump to call the enumerated functions.
Now that is very interesting, and certainly less dynamic than ObjC (e.g. no method_exchangeImplementations and other nonsense), and I would argue quite a lot saner for the scope of the XCTest problem. But it follows easily that as soon as we do that we could emit a program that uses that same function enumeration to emit a giant switch statement that does dispatch-by-string. Of course it would be opt-in, so only callers that wanted it would use it, but there's nobody to stop you.
All of that to say, I think what is actually happening inside Swift is we're coming up with more structured kinds of dynamism, rather than a knee-jerk reaction against the ObjC philosophy. ObjC's model certainly has its issues, and we have gotten surprisingly far without really much dynamism at all. On the other hand, Swift constantly hits cases that are "solved" by ObjC's dynamism, those are definitely real (doesn't get more real than the core libraries), and dismissing them out of hand would be stupid. Meanwhile it takes time to come up with solid "structured" approaches to all the various cases people use dynamism in the wild, so it will be a long process of enabling more and more kinds of dynamism over time.
As for the ObjC runtime, we will not actually have it for years. Maybe on Apple platforms. But the decision has been made not to ship it for Linux, and Linux is of course the next big frontier for Swift. All code that wants to run on Linux (or run on both platforms) better not use the ObjC runtime for anything ever. So this places increasing pressure on designers to figure out what our answer to all the dynamic usecases will be, because there is no seatbelt to save you on one of our platforms.
Basically, I would very much not be dismissing these critiques out of hand. They are not (other than a few) arguing for a return to ObjC. But they are raising issues not seriously solved by Swift at present, and we need to be uncovering those and putting in the design effort to generate solutions for them.
From my vantage point it seems to be the opposite of your analysis. While it is true that ObjC's dynamism has all kinds of problems we want to avoid, we're also running into lots of cases where the obvious solution is dynamism, and the other solutions aren't obvious.
One concrete example I can offer you is NSCoding, which is being reimplemented right now in corelibs-Foundation. That API pretty much needs a way to look up classes at runtime, (there's really no other sane way to provide the feature). You could argue that we don't need NSCoding (in fact that was argued), but ultimately, we decided we needed NSCoding more than not. So Swift 3 adds a `_typeByName` API which does dynamic lookups of classes by string. It landed, it exists, the ship has sailed.
Another concrete example that may be interesting is XCTest. The way XCTest works is your unit tests are written as functions on a class, and we "discover" the tests by enumerating the functions at runtime. But oops, Swift has no way to enumerate functions at runtime, so we can't find any of your tests. The solution to this problem is actually pretty interesting: the latest proposal is to do sourcecode analysis from the compiler to enumerate your test functions, dump that somewhere, and then generate a second program that uses the dump to call the enumerated functions.
Now that is very interesting, and certainly less dynamic than ObjC (e.g. no method_exchangeImplementations and other nonsense), and I would argue quite a lot saner for the scope of the XCTest problem. But it follows easily that as soon as we do that we could emit a program that uses that same function enumeration to emit a giant switch statement that does dispatch-by-string. Of course it would be opt-in, so only callers that wanted it would use it, but there's nobody to stop you.
All of that to say, I think what is actually happening inside Swift is we're coming up with more structured kinds of dynamism, rather than a knee-jerk reaction against the ObjC philosophy. ObjC's model certainly has its issues, and we have gotten surprisingly far without really much dynamism at all. On the other hand, Swift constantly hits cases that are "solved" by ObjC's dynamism, those are definitely real (doesn't get more real than the core libraries), and dismissing them out of hand would be stupid. Meanwhile it takes time to come up with solid "structured" approaches to all the various cases people use dynamism in the wild, so it will be a long process of enabling more and more kinds of dynamism over time.
As for the ObjC runtime, we will not actually have it for years. Maybe on Apple platforms. But the decision has been made not to ship it for Linux, and Linux is of course the next big frontier for Swift. All code that wants to run on Linux (or run on both platforms) better not use the ObjC runtime for anything ever. So this places increasing pressure on designers to figure out what our answer to all the dynamic usecases will be, because there is no seatbelt to save you on one of our platforms.
Basically, I would very much not be dismissing these critiques out of hand. They are not (other than a few) arguing for a return to ObjC. But they are raising issues not seriously solved by Swift at present, and we need to be uncovering those and putting in the design effort to generate solutions for them.