TeXworks
Consider switching to QJSEngine
On macOS, the hardened run-time must be enabled for the MiKTeX variant of TeXworks (because the whole MiKTeX bundle is notarized).
Unfortunately, the executable crashes unless the disable-executable-page-protection run-time exception is added to the executable. But that's not a good solution: to cite Apple, this "removes a fundamental security protection".
I would recommend that QJSEngine is used in a future version of TeXworks (QScriptEngine is kind of deprecated). Maybe this fixes the hardened run-time issue.
The page you linked applies to "an app that attempts to directly modify sections of its own executable files", e.g. when updating itself. TeXworks currently does not have any update mechanisms built in (and, AFAICT, should not modify its files). So this may be a modification implemented by the MiKTeX devs - in which case this issue should be reported to them.
ATM, QJSEngine does not feature, e.g., a debugger (QTBUG-55905), so I'm a quite reluctant to proceed with what is likely a relatively major change to the scripting code.
Does the problem you mention also occur with the non-MiKTeX builds of Tw (e.g., the stable releases found here on GitHub or the latest development versions found on Bintray)?
As I said before, hardened runtime must be enabled in order to reproduce the crash. If I understand correctly, all official TW executables are not notarized (hardened runtime not enabled). (Side note: that makes me wonder, how users are supposed to run them under Mojave.)
I understand that you don't want to change a working solution. That's fine with me (I have a work-around, see above.)
But I would recommend that you enable hardened runtime in the near future, or users will not be able to run official TeXworks executables if Apple decides to close the door for unsigned/non-notarized apps.
Thanks for raising the point of hardened runtimes (although it would probably fit better in an issue of its own).
I am not a Mac developer myself (I don't even have a Mac), so any changes to the Mac build pipeline will be difficult for me to implement and test. That being said, the current pipeline uses homebrew for building, and from a discussion on their forum, it seems that homebrew does not provide signed libraries to begin with...
Third-party binaries (Homebrew, Qt) can be signed subsequently after adding them to the bundle (i.e., everything under TeXworks.app/Contents/{Framework,MacOS,Plugins,bin,lib}). You use the find utility and codesign to do the job. Only drawback: you need an Apple Developer ID (one year membership: EUR 99) to get a certificate. Maybe you can ask TUG to get funding.