Because the end user shouldn't have any debug access, only the developer. Errors should be handled in application. In worst case (total exit of process from an error) Most people don't have error handling anyway. (And I don't want the only tool required to evade the license check to be notepad + asar)
That's what it really comes down to. From what I can see, it's mostly an emotional response. I'd be surprised if code/binary obfuscation is a net win in general.
I've had to disabuse developers of this idea. One distributed binaries that weren't quite valid but ran on the CLR, though not Mono. A 10 line script was enough to remove the invalid sequences. What did the developer gain in this case? An extra build step, undoubtedly more than one bug, and in the end, no "protection".
I agree with the idea that anything can be reverse engineered. However electron by default has plain text javascript code. I'd like to prevent people from editing plain text (!!!) to evade my licensing check!
For what it's worth I agree with the Electron dev's decision to close the ticket. They don't seem to have the same use case as you and are under no obligation to support it.
There's also the unstated issue of ongoing support for the feature. If they put in code obfuscation they'll be obligated to make sure that it provides adequate protections to avoid a deluge of "someone hacked my obfuscated code" type tickets. What constitutes "adequate protections" will have to be updated over time as more advanced techniques are discovered for reversing out the code.
Combined with the performance drops that were clearly outlined by the Electron devs it would seem like a code obfuscation feature could be a really big waste of time.
Perhaps try hosting a page with a crack or serial for your product and see if there's significant usage in the first place? My guess is people are more worried about this than it warrants. A user of professional tools opting to edit the source code of a tool every time it updates seems like they might not be a paying customer in the first place.
I guess "source code protection" is for distributing plugins for Atom without distributing the source so the code isn't accessible. So I would call this "source code concealing". In any event, this could be done with WASM.