<p>From the MSDN documentation:</p>

<p>"Synchronized supports multiple writing threads, provided that no threads are reading the Hashtable. The synchronized wrapper does not provide thread-safe access in the case of one or more readers and one or more writers."</p>

<p>Source:
<a href="http://msdn.microsoft.com/en-us/library/system.collections.hashtable.synchronized.aspx" rel="nofollow noreferrer">http://msdn.microsoft.com/en-us/library/system.collections.hashtable.synchronized.aspx</a></p>

<p>It sounds like I still have to use locks anyways, so my question is why would we use Hashtable.Synchronized at all?</p>

For the same reason there are different levels of DB transaction.  You may care that writes are guaranteed, but not mind reading stale/possibly bad data.
EDIT
I note that their specific example is an Enumerator.  They can't handle this case in their wrapper, because if you break from the enumeration early, the wrapper class would have no way to know that it can release its lock.
Think instead of the case of a counter.  Multiple threads can increase a value in the table, and you want to display the value of the count.  It doesn't matter if you display 1,200,453 and the count is actually 1,200,454 - you just need it close.  However, you don't want the data to be corrupt.  This is a case where thread-safety is important for writes, but not reads.