The first time you're bitten in the behind by a subtle bug after a couple of hours searching you've given up a hundredfold the time you have saved up to that point by not having to type those ;s. At that point people usually 'get it'.
I don't really get what you call implicit when you terminate statements with semicolons instead of linebreaks... ... Ok, I get what you're hinting it: there are some (very) few exceptions. However, I cannot see where there is any 'optimisation' in using linebreaks instead of semicolons. You better need to explain why someone should use both linebreaks _and_ semicolons, when only using linebreaks is actually as good as well.
Basically, it's just a matter of style. Aside from a few exceptions (e.g. described in http://inimino.org/~inimino/blog/javascript_semicolons), linebreaks terminate a statement. If you stick with writing only one statement per line, I don't see what's so implicit with it. Rather terminating a statement both with a line break and a semicolon is a tautology, and hence introduces unnecessary redundancy.
The actual question is, whether one can require that developers know the (maybe a handful) exceptions where a line break doesn't terminate a statement. I have decided (for myself) that I can require that knowledge, as it really comes down to only a few exceptions (that I believe are easy to remember).
But, of course, I'm aware that one can also come do another reasonable conclusion.
The only important thing is that people make a concious decision about the issue at all. The importance of this increases with the number of people that are working together on a particular project.
Here a link to another article discussing that issue: http://mislav.uniqpath.com/2010/05/semicolons/
x = y
/* TODO: clean this up to make it more readable
* and maybe add some semicolons
*/
+ 4
This is a really nice example of that.
It also is reminiscent of one of my favourite programming jokes:
int x;
int y;
x = 0; /* initialise both x
y = 0; and y to 0 */