But for macOS it's way easier, and more needed. It actually silences the scary warnings. It's even a real security improvement, as you get your app's keychain protected.
This is very much not true - if you have unsigned executables for an app of any scale, 3rd party AV will be extremely Unkind to your app, especially if you try to do updates. Also, how long your app gets blocked depends on how many downloads you get, if your app is popular it can be unblocked in a matter of hours, and once a download URL is deemed trusted, this is largely a non-problem.
Also, while I'll 100% agree that CAs on Windows are a nightmare, the tooling is extremely straightforward, signtool.exe takes your cert file, a password, and an executable, then signs it.
And tooling for managing the certs is another pain. Mine required entering a PIN from a GUI every time certs were touched, so I couldn't automate the builds.
At any rate, I think having unsigned binaries that are not notarized introduces additional hoops for non-expert users, since macOS requires signed bundles by default (which is a good thing!).
To come at it from another direction, why is it your users' responsibility to work around your own cheapness/laziness? Just front the $100 and sign your damn app, especially if you're making money with it.
Moreover, signatures and notarization are there for a reason. Code signing makes it more likely that the bundle was not tampered with. Apple can revoke the certificate if the developer key leaked. Notarization will catch at least some forms of malware.
I refuse to run unsigned code (with one exception), because it decreases security significantly. There have also been severe incidents in the past with unsigned code, e.g.:
https://blog.malwarebytes.com/threat-analysis/mac-threat-ana...