Here's a pros and cons list. This answer is marked as "community wiki", so feel free to edit it and add more pros and cons. Realize that you might not agree with all of the pros/cons on these lists - I certainly don't, but they're still there to represent the points of view out there. Also remember, a longer pros list does not automatically make it better.
The term ASI will be used frequently, and means "Automatic Semicolon Insertion" - this is the (broken) algorithm Javascript uses to decide where semicolons belong when they're omitted.
Pros of using semicolons
It is easier to remember to add a ";" at the end of each line, then to remember the rules of omitting semicolons. (However, see the final point at the end about why it's still worthwhile to know how ASI works)
When coding without a linter (or with a not-so-good linter), you're a lot less likely to bump into ASI issues.
It creates less friction when teammates often switch between other languages that require semicolons, such as C++ or Java.
It makes code intention very clear and unambiguous.
This has already been the long-standing "standard", many online code snippets are written with semicolons, which makes for easy copying-pasting. Why segment the community?
There is no guarantee that the "safety rules of omitting semicolons" will stay stable. For example, it's been argued that there's a handful of places where ASI hazards could come into play, but only a couple of them matter for any non-contrived piece of code, and those can be avoided by putting a semicolon before a [ or (. However, the introduction of the upcoming pipeline operator will bring a number of new places where we have to watch out for ASI hazards (like, const value = 2 \n -3 |> f(%) will be treated as one statement, not two).
Pros of omitting semicolons (and instead adding them before [ and ( at the beginning of lines)
It creates less friction when teammates often switch between other languages that don't require semicolons, such as Python. (It can be annoying to often go back and insert forgotten semicolons).
Semicolons can feel like extra visual clutter
Smaller diffs (to help avoid merge conflicts).
e.g. changing
array
.filter(...);
to
array
.filter(...)
.map(...);
causes two lines to be changed instead of one.
If you're often starting lines with [ and (, then you're probably doing more advance techniques, and it might be worthwhile to dumb down your code anyways. e.g. use a normal for loop instead of ;[1, 2, 3].forEach(...).
If you're not using a minifier, it makes for a slightly smaller byte count. Automatic gzip-compression mitigates this issue if enabled on the server.
It's still possible to bump into ASI issues when coding with semi-colons (although it's much less common). A commonly cited example is the following (incorrect) attempt at returning an object. This code instead returns nothing, because a semi-colon will automatically be placed between return and {.
return
{
x: 2
};
Less keystrokes
The answer to the original question (Why the recent shift to semicolon-less code?) is that it really comes down to personal/team preference. It's not until recently (because of the popularization of the safety rules of semicolon omission) that those who don't like semicolons can feel free to actually omit them in a professional setting. This has caused a major shift with many groups of people choosing to leave semicolons out. This is all done because of personal, team, or company preference, not because it's objectively better (though some may argue otherwise). In other words, it's not that the entire community is changing its opinions to now prefer semicolons, rather, the community members who already prefer to code without semicolons now have the means to do so.
As a final point, I want to make an important point clear. Semicolons are not a substitute for linters. Once a good linter is in place, you'll never run into ASI issues, no matter if you choose to use semicolons or not. But many people do not use linters 100% of the time (which is reasonable). Without a linter, you're going to run into ASI issues no matter which route you choose. Yes, even semicolon users will bump against ASI - such an issue was recently stumping a friend of mine (it's easy to forget a semicolon after doing const fn = function() { ... }). For reasons such as this, it can still be worthwhile to learn how ASI works, even if you choose to put semicolons everywhere.
You'll find that many of the pros/cons listed above vanish when good tooling is used and many others are very subjective, which is why it really just comes down to people's preferences.
