I'm just taking a stab at this, but looking at the source for java.util.Collections, it appears that synchronizedList() just wraps the unsynchronized list with a synchronized List implementation. This would mean that every method call to the synchronized list would involve another method call to the underlaying unsynchronized list. That's additional overhead, but I doubt that you'd see much of an impact in any real-world application.
The performance cost of synchronization is often overstated. An important issue is: is there contention for the lock from other threads? A more important issue is that code that relies on the internal synchronization of either Vector or synchronizedList() is usually defective anyway, and requires additional external synchronization to make it safe. (It's rare that you can do anything useful with a List that doesn't require at least two method calls, and you need to prevent other threads from changing the data between calls.) Once you put in external synchronization, the internal synchronization becomes pointless. Consequently, between Vector and synchronizedList(), my answer is: who cares?
In comparison, a Hashtable or synchronizedMap() is sometimes useful, because put() and get() can be useful as atomic operations without necessarily requiring other method calls. Last I checked, it seems Hastable could be slightly faster than synchonizedMap(), for the reasons Joe just described. But the effect is usually negligible, and I usually would prefer to use the more flexible newer classes, just on general principle.