I don't think that plugin catches floating promises, i.e. promises that are not waited (either via await or then/catch method). The rules listed in that package's readme don't seem to mention it at least (unless I'm totally misreading something). You kinda need TypeScript for that because you need the type info to know if a value whether some value is a Promsie to give the warning.
If you add a catch block it will be even worse, all errors inside a promise callback will then become soft errors. Only add the catch if you actually plan to handle the error.
I can't speak to the front-end, but there are plenty of situations in dealing with node where the correct thing to do is to throw a fatal error. If you have properly setup handlers for the end of the process lifecycle I don't see what the problem is.
Absolutely! I guess what I'm trying to say is that in my experience, crashing on an unhandled rejection is a better remedy to the dangling promise problem than banning them outright.
There is a saying - what you don't know can't hurt you.
The idea of Promises comes from strongly typed static functional languages. Adding it to JavaScript was a terrible idea. Like with static modules - forcing the user to download the whole website/app before anything is rendered on the screen.
It's unfortunately not on the recommended list. For very few circumstances the rule doesn't make sense, but most of the time that shows bad programming design.
Not now, but it's planned to be starting with the next major version. They are holding off until then since changing the default rules is considered a breaking change.
But, I agree with your point, that rule can catch a lot of bugs.