Every language since has had to pick a side, and "optional" always turns out to be the hardest choice.
JavaScript's ASI is what happens when a 10 day language has to live with a quick pragmatic decision for 30 years.
The problem discussed in the parent article was already solved correctly by 1965, 60 years ago, in the language CPL, the ancestor of BCPL, which is the ancestor of C.
It is sad that decades later, most programming languages remain worse from this point of view.
In CPL, a command or definition is terminated by a semicolon or by an end of line unless the end of line occurs at a point in the program where the context indicates that a command or definition cannot terminate at that point.
This means that only a minimum number of semicolons are needed, when you want to write multiple statements on a single line, and no special characters are needed to mark that a statement is written on multiple lines.
Before CPL, some languages terminated statements with semicolons, while others with new line characters. CPL was the first to allow either method of termination, and also where new line characters may terminate or not terminate a statement, depending on the context.
Thus CPL combined the advantage of ALGOL-like languages for writing statements on multiple lines with the advantage of FORTRAN-like languages for not requiring semicolons in most cases.
"where the context indicates that a command or definition cannot terminate at that point" is trivially unsuitable for C-like languages, `if`-`else` already violates that, since an `if` can terminate before the `else` by that definition (imagine splitting `else` to a new line).
An actually workable definition would be "unless the end of line occurs at a point where the current expression can not be terminated or the next tokens are not parseable as a separate statement", which is almost the definition of semicolon insertion in JavaScript....
But JavaScript has exactly the problem of the ambiguity since both braces (via object literals) and parentheses (via expressions-as-statements) can start a statement and those are ambiguous with eg. blocks and function calls, respectively.
C is an example of how the syntax of a programming language should not be designed and unfortunately many languages whose claimed purpose was to correct various shortcomings of C have nonetheless inherited the quirks of its syntax.
C has attempted to avoid the use of braces/parentheses/brackets in certain contexts and it has attempted to minimize the number of keywords, but the end result has been the opposite, a typical C program has much more parentheses, braces and brackets than the same program written in a language with a better syntax, like ALGOL 68, or like a non-verbose version of Ada, where the Ada abstract syntax would be preserved but most Ada keywords would be substituted with symbols (such a non-verbose Ada can easily be implemented with a source preprocessor).
In my opinion, a good syntax is of the kind usually called "fully bracketed", as popularized by ALGOL 68, where there are no ambiguities about the extent of a program structure (like the one mentioned by you with C "if", such problems do not exist in ALGOL 68, Ada and similar languages) and there are no alternatives of the kind that exist in C between using a simple statement or a compound statement, i.e. in any location it does not matter if one or more statements are written (this is the feature that makes the specification of statement termination that was used in CPL work without problems), and where several kinds of different brackets are used, not a single kind, e.g. there should be different kinds of brackets for blocks, loops and conditional statements.
Most of the problems that exist in the syntaxes of many popular programming languages are caused by the use of the ASCII character set, which has too few symbols, so it forces the use of some symbols for multiple purposes, which causes ambiguities for parsing.
When Unicode is used instead of ASCII, it is possible to use every symbol for a unique purpose, including the use of different kinds of brackets, and this makes very easy to design a syntax that avoids any kinds of parsing ambiguities.
