`window.onunhandledrejection` is a part of the spec, it simply took a bit for browsers to catch up to it.

It's a different handler because an application may need to know the difference between a synchronous error and an asynchronous error and handle them (dramatically) different.

If there is a need to distinguish between different kind of errors then it can be done by checking error prototype (if (error instanceof AsyncError) { ... }). There was no need to introduce a new event.

I think the reason is because some developers have a kind of exception-phobia and they prefer to hide errors (make developer check for them explicitly) rather than let them bubble up.

I see this in other platforms too. For example, in .NET if a background thread crashes because of unhandled exception then nothing happens to the main thread, no error is reported. The developer must check for an error and of course most developers won't care about this.

Another example is how error reporting is done in a browser. JS errors are never shown to the user so if a rich JS app has an error the user won't know about it, the app will just stop working or show invalid data.

Browsers have a long backwards compatibility story to deal with and the interplay of synchronous errors and the synchronous error event is a part of that. Just because you don't see a need to introduce a new event doesn't mean bright minds didn't think about it.