One very important one is that, empirically, it showed how much of what we think we know about language design is ... shall we say ... "incomplete".
After all, Objective-C is a car-crash of a language: take some Smalltalk and jam it into C. Done. How can you write software with this? And yet NeXTStep and Cocoa/CocoaTouch, arguably the most elegant pieces of OS-level/UI-framework software ever, were written in Objective-C. And not despite of it, but because of it.
From a safety standpoint, it's hard to see how you can get worse: all the static type safety of Smalltalk (none) combined with the memory safety of C (none). And these interact.
And while it certainly is possible to use it very, very badly, in practice I haven't seen the horrors that we are supposed to get.
https://blog.metaobject.com/2014/05/the-spidy-subset-or-avoi...
As an example, we got the same level of improvement from doing an Objective-C → Objective-C rewrite with Wunderlist (from WL2 to WL3) that others claim for Objective-C to Swift transitions.
Also, dynamic messaging is said to be slow, yet Objective-C programs consistently outperform the much more static Swift ones.
https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie...
And of course, we all know that to do dynamic OO, you need a large runtime and better yet a VM. But it turns out that you can get much if not all of it with a tiny sliver of an extension to portable PDP-11 assembly language.
https://blog.metaobject.com/2024/08/objective-c-is-just-like...
With so much being provided by so little, you can actually put the rest of the language design space to better use, IMHO: