Once long ago this was considered easier than using a terminator such as
';' -- a prime example was FORTRAN. How many remember the thrill of
having their IBM FORTRAN II compiler patched to recognize record-mark (a
0-2-8 punch) as a statement terminator, making it possible to punch TWO
statements per card?

For a more modern and widespread example, there's the C preprocessor,
where macros are parsed as one line, though they're often written as
multiple lines ending with '\'.

Actually I like the idea of using EOL rather than ;. It eliminates a
cause of several common errors in compilation that need not happen, and it
need not have particularly adverse side effects.

Here's one example of a human factors trap in C that wouldn't be there
without ';'. The key is C's syntax definition for <statement> -- either
one simple statement terminated by ';' or a sequence of simple statements
surrounded by {}'s.

But if your brain kicked in with the notion that SOME_MACRO(a,b)
invocation looks like it should be a statement, and you automatically
coded it as

if ( a == b )
SOME_MACRO(a,b);
else
...

then the extra ';' terminates the entire 'if' statement and the following
'else' produces a syntax error. Or if you had left yourself open to the
dangling else problem in nested if's, it's possible to get no syntax error
but instead to get a surprising flow of control.

There's a second-level trap here too, based on using knowledge of
semicolons in software tools. I once saw someone encounter the trap above
when his automatic-indenting software demanded that the macro invocation
look like a statement, ending with a ';'. To accommodate this autoindent
software he took existing code that had been correct and appended a ';' to
each macro invocation. At least it caused no harm on MOST of the macro
invocations...