Lazy or Implied JOINs are a bad habit. If someone is comfortable with it you shouldn't chide them. Not only is good to know the proper way once you get deep enough to want RIGHT OUTER JOINs and such but the syntax will rescue you from the dreaded "dot product bomb".

See, without a join constraint, SQLs only choice is to join the first row of one table to every row in the next, and then the second row etc etc. A three table join of 10,000 records in each table, each a tiny 100 bytes will return at least 100,000,000,000,000 bytes of data plus framing and protocol and such.

People rarely forget the ON xxx=yyy clause off the end of the JOIN but often when tinkering or generating code you wind up with an incomplete WHERE. I've personally seen a perl script kill a $200,000 SGI box with 1.5GB of total memory. Just shut it down, ate every drop of memory and was still trying when we finally got a root terminal to except "killall perl<RET>" at the blazing speed of 1 char every 5 seconds. =)

When speed of data return matters, and the optimizer fails you, at least you'll be able to reorder the JOINs without refactoring the whole deal. And about 90% of the time, the natural order you follow will be the right thing.

As to the MySQL notes on keys and the need for constraints I say a hearty Amen Brother!

--
$you = new YOU;
honk() if $you->love(perl)