The problem with disabling notarization, is that it's something any trojan-horse malware author would have a glossy slideshow walking you through doing as part of the install process for their "meet sexy singles in your area and double your money instantly!" app.

And then you'd run the app, and it wouldn't blow up your phone, but just be a bit disappointing and something you'd delete — but meanwhile, the app would have used some 0day exploit to get a foothold outside the app sandbox, and so now your phone would be a silent node in a botnet, able to be C&Ced to DDoS targets or act as a VPN for nefarious account registrations or so forth.

(Did you know that there are many such botnets made of Android devices? But none so far for iOS devices. There's a reason for that!)

---

If it's not clear, by the way, Apple's "notarization" is, under the covers, just plain-old code signing. Just like every modern consumer OS has for apps, regardless of whether you get them from an app store or from the web. So that the platform can protect users from obvious viruses by just revoking the code cert.

Mind you, notarization is code-signing that requires you to submit your binary to Apple... but it's my understanding that this notarization still operates in two phases — a quick, synchronous phase, and a slower, asynchronous phase — and that the synchronous checks in the notarization process, before you get your cert signed, are only checks against the known signatures of various exploit techniques. (Again, just like every other consumer OS comes up with some way to get done — whether that be through required submission at signing time, or by submission of novel software by virus scanners that find the software on your disk, or even by web browsers as they download the software. Just try to develop Windows software, on Windows, without implicitly submitting binary "samples" to Microsoft through some route or another. It's very hard!)

Apple is somewhat unique among platforms, in having certain other virus-signature like patterns that their notarization backend takes note of, that won't trigger synchronous rejection, but rather will trigger Apple employees to do an async review of the application. (AFAIK, when this happens, you still get your app's cert signed right away; the cert might just get blacklisted some time later, if it turns out under closer human scrutiny that you were in fact doing something malicious.)

It is my understanding that the things Apple flags for human investigation, consist of use of certain system framework calls, that only very powerful and low-level system software should be doing — think, the sorts of calls unique to Virtual Machine hypervisor software, or to third-party file-system driver software. Rootkit code-smells, in other words.

Note that none of this is about what your app does for the user. Apple's notarization system — as Gatekeeper on macOS, or as part of Enterprise MDM iOS app deployment — has never suppressed or censored any app due to its nature. It's only about what it's doing that it's not supposed to be doing "according to what's on the tin." Apple is doing the same thing through notarization that the FDA does to foods and drugs: holding companies to their claims of their products being fit-for-purpose and non-adulterated.

(And although this is currently entirely a thing Apple is simply trusted to do in good faith, there's nothing stopping the EU from mandating that Apple's notarization going forward, consist of exactly these kind of technical checks and no more. I think that'd be a great idea, personally.)