I'm starting to research this to better understand its implications as well, since I installed a number of 3rd party apps on my laptop and never use the store. Everything I install is either DMG or via brew.
Background & Python
For starters I would suspect any applications that are in binary form would be what Apple's referring to when they executables have to be notarized. A Python script, though executable, is not technically a binary, the shebang, #!/usr/bin/env python at the top is what makes it executable, so I would expect that only the literal /usr/bin/python binary would need to be notarized to appease GateKeeper.
APIs
If you look through the documentation around Notarization, you're uploading your build artifacts from your project to an Apple server where they'll analyze it and then provide a will return a unique ticket that you'll need to "staple" to your application. This ticket will allow GateKeeper to later verify your application for authenticity with Apple.
So they won't be doing anything through high level APIs, but rather through forcing applications to use macOS 10.9 libraries or later SDKS, per this bullet:
- Link against the macOS 10.9 or later SDK.
So they will be restricting applications through low level libraries (APIs) that they may be using.
Plugins
By default plugins will inherit whatever notary their native application they're running in will provide:
Notarizing Your App Before Distribution
Plug-ins don’t declare their own entitlements. Instead, they inherit
the entitlements of the host process. Therefore, a host app must
include all the entitlements that prospective plug-ins require, even
when the plug-ins are notarized separately.
However, this paragraph looks to state that basic plugins should be able to just work through their parent, but if they're doing something low level themselves, perhaps in some C plugin to Photoshop, this extra level of capabilities will need to be addressed by the parent app as part of its entitlement on behalf of the plugins that may run underneath the parent app.
Notarizing Your App Before Distribution
For example, if a plug-in employs deep integration with the host
executable via C function pointer overrides, or uses a JavaScript
engine for custom workflows, the host executable must declare the
Allow Unsigned Executable Memory Entitlement or Allow Execution of
JIT-compiled Code Entitlement, respectively. In some cases, a plug-in
fails to even load if the host executable lacks the proper
entitlement.
An author's perspective
I found this blog post from the author of Acorn, a commercially available image editor.
MacOS Notarization
And automating the notarization steps weren't as bad as I thought they
would be. I wrote a Python script which calls out to the notarization
tools with the addition of having the response format set to xml (and
it was in the plist format, which was then easily fed into
Foundation.NSDictionary). The script analyzed the current state of
things and either waited a while before querying the notarization
servers again to see if it's done, or stapled on the notarization bits
if it was. Then a new build of Acorn makes its way to the internet.
Notarization adds a few minutes to the build time, but maybe it'll be
worth it? I don't like having to depend on Apple's servers to put
something up on mine. But if notariation prevents those "Foo.app is an
app downloaded from the Internet. Are you sure you want to open it?"
boxes from scaring customers unnecessarily, it will be worth the
hassle. I can hope at any rate.
I felt like this author's perspective was reasonable. I've always just dismissed the warning when installing 3rd party software, but can understand some people's reluctance.
This article had some additional takes on Notarization that I found germane to you question but didn't want to overload my answer with too much more info. The article is titled: What the Apple Notarization Program for macOS Apps Means for You.
References
