This seems to be premature optimization. The author forced himself to learn archaic Objective C for a completely unnecessary reason, and now is stuck with that design choice despite not having any benefits.
Some benefits:
1) Most Swift code written in 2015 when the author was starting won't even compile today, because the language has changed in non-compatible ways. Whereas Objective-C code written in 2015, 2005, and possibly even 1995 will usually still compile and run. The author mentioned low maintenance costs as a goal.
2) Swift compile times are still vastly slower than Objective-C.
3) The Swift tooling is still buggy, including the compiler, and especially the debugger (the author wrote an entire section about debugging).
If I started a new app today, I'd use Swift -- it's mature enough. But in 2015 and for a long time after, it wasn't really a good option unless you wanted to be on the bleeding edge (and you were willing to bleed).
Compile times will always be slower than Objective-C, but the compiled code _can_ be faster, with effort. And maybe someone will eventually break down and write a Swift-centric debugger.
It's easy, now, to say that it was a poor choice/premature optimization/unnecessary/whatever. But, presumably, the author is unable to tell the future. At the time when the decision was made, there were benefits that the author deemed necessary (smaller distributable among other benefits).
Of course, the pressure to rewrite would grow with every year as Apple continues deprioritizing Objective-C, but that's a problem for future me. :)
So all the NS_SWIFT_UNAVAILABLE APIs are still easily bypassable in Swift?
I'd hesitate to put it that way.
Shipping software is always full of compromise, and we often have to stay away from the "bleeding edge," when we want to actually ship full-featured products.
I suspect that almost all the AAA apps are still ObjC.
I still use UIKit/AppKit for my work. I simply can't get the results that I need from SwiftUI.
Actually, building on stable abstraction is a pretty nice benefit when your focus is on the product.
Swift is quite nice, IMO, but has also changed quite a bit since 2015 and using it would likely have lead to a bunch of work to keep up.
The word that comes to mind after reading that post is “intentionality.” Many deliberate decisions, including for hard tradeoffs like this one. To me, that speaks to the importance of vision and judgment over the apparent correctness of individual choices.
Swift is lighter on the eyes, but it still uses the same APIs when paired with UIKit/AppKit.
SwiftUI is a different thing though. It's like React for UIKit/AppKit and has a different API.