Application extensions outside the Apple ecosystem have been used on Apple computers for decades. It was never limited to Apple provided systems, whatever that means.

This is incorrect. In the past apps like Photoshop have allowed plugins which differ from App Extensions by running inside the host app's process. App Extensions are run in a separate process and don't have access to the entitlements of the host application, and can't directly access its data. This tends to mean that extensions are much better behaved than plug-ins.

So, basically, OS support for the kind of things that Chrome and Firefox have been doing for a while?

Having been part of the Firefox effort, that was a real pain to implement, so sounds like a very useful component.

This. It is a different technical model that produces a different user experience. These are closer to widgets than to IPC.

Applications have been using out-of-process sandboxes for years. But that's not necessarily a sign of quality, since this comes with a performance cost.

It's nice when extensions don't crash the host application, but the mitigations aren't free. It's interesting that Swift's stable ABI will drastically lower that cost, since you usually need some kind of serialization (although people have been using mmap to share data between host/extension process for awhile too to avoid the serialization penalty)

(author of that quoted blog post here). You are correct, there's nothing new about apps offering plugins/extension systems. What's new here is: this works across sandboxed apps, support for remote (out-of-process) views, and the extension permission and discovery system is entirely managed by Apple.

Like I mentioned in another comment most of this has been practice for awhile. The big one is discovery, but there have been techniques to fix that (like standard install locations). AU (v2, v3) is a good example.