Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
If we are still only talking about serialization as it pertains to persisting an object on the file system (and not serialization in the context of distributed programming, i.e. when we need it to send objects between JVMs), I suppose when the overhead of a database is too much for the requirements of a particular application. If, for example, the application is a simple, single user desktop application why would we need the overhead of a database?
Serializable - the breakfast interface. Making sure we can pour milk over our JavaBeans and have them for breakfast.
Serialization is used not only to store object state to a filesystem, but also to send object state across a network. That's one of the reasons networking in Java is just as easy as interacting with a file system.
So, in a clustered environment, you may read a user object in from a database, but the clustered JVM might have to do workload management on the user object - maybe make it available to sessions running on different JVMs. If the object is serializable, then the JVM will be able to pass that Java object around like yesterdays newspaper. If it's not serializable, there will be problems.
That's just one, sorta hidden reason, on why it's important to make sure all JavaBeans are serializable.