Short, short version: imagine that Sun built a version of solaris that almost entirely replaced "shell" with a variant of Java that didn't *inititally* come with a stand-alone interpreter, but did add one later. Then: s/Sun/Apple/, s/solaris/macosx/, and s/Java/AppleScript/.
Longer version:
Since Apple bundles together the user toolkit, system UI, "window manager", and system services all behind a (sadly mostly proprietary) wall, native macOS applications that want to do "plumbing" use a scripting language called "Applescript", based very loosely around HyperCard. This dates back to the previous millenium, to well before the Unix-like Mac OS X was built from a combination of Mach, FreeBSD, and NextSTEP. In those days, there was no multi-user OS underpinning that understood things like shell scripts and forking processing. Applications that are "Applescript aware", which includes basically everything that comes with the OS as well as much of the 3rd party software could be interacted with using "code" like "tell application Music to play U2" or "tell application Mail to open new message addressed to
monopoly@microsoft.com" (as well as more complicated scripts with variables, logic, etc).
At some point, Apple regularized the OS-level interface to this language, and named it the "Open Scripting Architecture" -- presumably back when adding the word "Open" to every kind of software was de rigueur. The ns port of Emacs to macosx added the ability to use the system library calls that tie applications into the OS-level infrastructure, known as "the scripting system", "the scripting layer", or similar variants.
If memory serves, some time later macosx itself grew a unix-level cli for this system itself, which is where "the osascript executable" came into play, which allowed mixing between Applescript and other scripting languages (I have seen both perl and tcl code that "automated" macosx by generating AppleScript and feeding it to the system, probably via osascript or a predecessor thereof). Before then, applications needed to link to the built-in system scripting libraries and call the related functions.
In emacs, there are a few nice things that can be done by having Emacs ask the OS to execute Applescript. Some of these, *in theory*, benefit from not needing to fork an interpreter each time. In practice, macos these days (note: I stopped using it regularly several years ago) has more or less enough of a unix-like underpinning that people can mostly use the same sort of inter-process techniques that they use on other operating systems. The remaining areas of friction come from interacting with the system software; for example, asking the default web browser the URL of its various windows.
From my point of view, this pretty clearly falls into the category of native application support on a proprietary OS. It's not enabling anything that doesn't already exist, by definition; but it is potentially making life easier for Emacs users on that platform. In practice, there wasn't a lot of upside when last I looked, so it probably doesn't warrant a lot of effort to continue, but there are a few platform-standard things that it enables that are useful and benefit from calling a library function rather than forking an interpreter. Of course, that relies on there being someone willing to maintain the glue to those library functions.
Hope that helps,
~Chad