In all seriousness though, it's incredible what Fetchnotes has accomplished, especially considering that every member of the team is still in college. Dropping out isn't always the answer!
I'm a fan of his closing statement, though this sticks in particular:
"...there is room for indisputable certainty, that is, initial choices that make unexpected events harmless."
I also code by the ideal that you should have a fine line between expected and unexpected behavior, and generally avoid tacking on special cases as your needs grow. Of course, various realistic constraints make can make this difficult, but that's why it's an "ideal". :-D
I think your camelCase example really nails it. Code should be written in a way that is both non-ambiguous and idiomatic to the existing codebase.
If you're in a position where you can define that idiom, then by all means do so. But stay consistent so that when others join a project, or you leave a project, the intent of your codebase is well understood without needing to wade through pages of documentation.
So, IMO, while semicolons are important, they're relatively trivial and an easy "bug" to fix. If I'm looking for an authority, I typically check out the Google Style Guides.
A similar, though more pressing issue that I've faced recently is the proper parenthization of conditions for if. It's generally nice when you don't have to spend a minute or two remembering/looking up the nuances of C++ operator precedence. Know all of the intricacies and tricks for a language doesn't mean every member of your team knows them that well either.
In all seriousness though, it's incredible what Fetchnotes has accomplished, especially considering that every member of the team is still in college. Dropping out isn't always the answer!