Public. Why bother? I never used it, and never had a problem. But Unity 3b4 introduced this issue where if you do not use it, and then you declare a public variable, you'll get a warning if you don't give the variable a default value. But I don't want to do that, because I use public variables purely so I can assign them in the Inspector! I reported this warning issue as a bug to UT, and support told me about how to solve it by using "public" in front of the class name. That's a lot cleaner than having to use "= null" or whatever, after all the public variables, but it still seems useless to me.
Actually, I'm a bit surprised that Unity does allow you to get through without the "public". When omit the "public" it means that your class is accessible "internal" which means
The type or member can be accessed by any code in the same assembly, but not from another assembly.
(Source: Access Modifiers (C# Programming Guide))
In Unity, as your scripts are accessed from the game engine runtime which is not your code assemblies (all scripts of the same language get compiled into a DLL; editor scripts and I think also plugins are compiled into separate assemblies), actually scripts which are not declared public shouldn't work, IMHO, because they are accessed from outside their assembly.
So, in general, I'd always create public classes unless I really want my classes to only be within the current assembly (which is rarely the case - would be the case for very special purpose helper-classes, though).
For a deeper understanding of encapsulation (which is what these access modifiers are all about), Wikipedia is a good starting point: Encapsulation (object-oriented programming). Another nice section about encapsulation can be found in the main Object-oriented programming article.
I can't say what UT's reasons are, but if you simply want to get rid of the warnings, you can (in C#) use pragmas - Disable warning messages, for instance
#pragma warning disable 0168 // variable declared but not used.