Why not? It is probably more for documentation purposes than anything else - ie just so the javadoc will explicitly state it, rather than the reader having to KNOW that it extends a class that implements serializable.
Because Serializable is a marker interface, any class that is indeed serializable should include this interface in its class declaration.
I can create a class with all, boring Java data types and call it serializable. Then I can subclass it and add an instance variable that is of type DataSource or DatabaseConnection, which isn't declared as being transient, and isn't serializable. In this case, I have extended a class that IS serializable, but my own class is indeed NOT serializable.
Does that make any sense?
By the way, if you extended a Serializable class, but added instance variables that weren't Serializable, would you be a "serial killer?"
I'm not satisfied with the above answers There must be a decent reason to decide to set this class Serializable. Servlets are not supposed to hold states, so I can't understand either why it has to be Serializable. Any relation to distributed environments ?