Not wrong, but funnily enough, it's a linting rule win. I'd go nuts if I didn't have my type checks and my linters. My current L, though, is setting up the projects initially and dealing with the configuration files if I raw dog it, but that's a problem with ESLint configs and the ecosystem as a whole having to deal with those headaches. So in the end, the JS devs got clever and shifted the blame to the tooling. 😅

I can see the benefit of matching style when working with others. I only code for myself and never had to worry about conformity for project consistency.

It is good to learn new things.

I'm sure I have some coding habitats that would annoy others.

I don't have experience with how it affects JavaScript specifically, but independent of programming language, it usually removes the guesswork where the error might be.

The thing is that compilers use fairly static rules for their grammar. So, even if you just typo a comma where there should've been a dot, then its grammar rules don't match anymore and it doesn't really know what to do with your code.
To some degree, it's possible to say certain symbols just cannot appear in a specific place, but especially with a comma, it could be the start of the next element in a list, for example.

Without semicolons, it's likely going to tell you that something's wrong between somewhere before your typo and the next closing brace (}). With semicolons, it can generally pinpoint the specific statement where the comma is wrong.
This should also make analysis quicker while you're editing the code, as it only has to check one statement (or two, if you're inserting a new line and haven't typed the semicolon yet).