It’s about backward compatibility of source and bytecode, really. It’s all that existing bytecode that’s really hard to have a rationale for breaking, so we’re only likely to see deprecated things being outright removed in another major version of Java (which I doubt will ever happen).
Yep, compatibility of things like savegame files and maps and such is kind of a pain for a shipped game, and patches often include code to upgrade those files. A common convention is to say that any version prior to 1.0 is “unstable” and could break compatibility at any time, and sorry, no old save games allowed. Dwarf Fortress for example typically does this (though DF will probably be permanently a 0.x thing).
When you serialize an object, it’ll try to serialize every field not marked “transient”. If a field is an object reference to something that isn’t Serializable, it’ll throw an exception. As for what breaks versions, the javadoc oddly enough suggests it’s “compiler-dependent”, i.e. any change at all could require a new serialVersionUID. In reality every JVM implements this spec: http://download.oracle.com/javase/6/docs/platform/serialization/spec/version.html#6678