Gus Mueller of Flying Meat writes about Mac development and the Acorn image editor, Retrobatch and Apple platform changes.
HN links it for Acorn's SQLite-based file format, and commenters also point to its posts on pricing and Mac development.
It doesn't sound like you've read any of the articles. There are details and tradeoffs and limitations found by the people talking about them. And there is a massive knowledge vacuum because if there is a good solution, it's not something that is obvious and well discussed by Apple. Ignoring and dismissing them doesn't make them actually go away.
Here's two on just the Responder chain:
http://inessential.com/2016/05/17/responder_chain_followup
http://shapeof.com/archives/2016/5/dynamic_swift.html
The bigger point (which is in that first Brent Simmons link) is that people have built all sorts of frameworks and tools over the past 20 years depending using of the dynamic features of Obj-C. Some are Apple's like all the above plus others like Interface Builder and XCTest, but other people have built their own things too that rely on the same concepts. How do these people move forward in a Swift world?
None of these people are arguing that Swift is terrible and going back to Obj-C. They are trying to use Swift. They are only interested in solving the problems they have (and well). When Swift fails to solve a problem or is far worse than its predecessor, there is a problem.
Not everybody can nonchalantly throw their stuff overboard like you are willing to do with Core Data.
Yes, it's a mixed bag with some things better and others worse. But having a great JavaScript engine with the JIT enabled is pretty important for many applications.
But breaking up the browser into different processes and communicating via messages and sharing textures in GPU memory between processes (IOSurface, GL_TEXTURE_EXTERNAL_OES, etc) is the inextricable direction of progress, what all the browsers are doing now, and why for example Firefox had to make so many old single-process XP-COM xulrunner plug-ins obsolete.
IOSurface:
https://developer.apple.com/documentation/iosurface?language=objc
https://shapeof.com/archives/2017/12/moving_to_metal_episode_iii.html
GL_TEXTURE_EXTERNAL_OES:
https://developer.android.com/reference/android/graphics/SurfaceTexture
http://www.felixjones.co.uk/neo%20website/Android_View/
I think the UI is cleaner and more Mac-like; Pixelmator felt a little too comfortable throwing consistency and OS X UI standards out the window. It's been a while since I tried Pixelmator, though, so maybe this comparison is no longer fair.
Also, though it probably won't matter for most people, Acorn's file format is pretty ingenious: http://shapeof.com/archives/2013/4/we_need_a_standard_layered_image_format.html
The Mac image editor Acorn uses SQLite as its file format. It's described here:
https://shapeof.com/archives/2025/4/acorn_file_format.html
The author notes that an advantage is that other programs can easily read the file format and extract information from it.
Here's an excellent blog post that explores that option (at the end):
http://shapeof.com/archives/2012/03/brent_simmons_on_deflation_and_introductory_pricing.html