I have been using Wicket for so long that I take it for granted that Wicket is serialization centric and haven’t thought about the the theory of it in a long time.
This somewhat dated page nicely describes the philosophical difference between wicket and more Servlet API centric frameworks: https://wicket.wordpress.com/tag/difference-between-wicket-and-struts/
Because wicket is maintaining a conversational flow with each client using a programming model that sort of resembles swing, It needs a mechanism to let many concurrent conversations carry on this model. To do it serializes and reconstitutes components (pages, page fragments, and models that represent the data that is being operated on).
So far, I’ve chickened out of making my own liquibase fork and making those classes serializable. Instead I made my own classes and copied the data from the liquibase classes that have that information.
In conclusion, my life (and maybe other developer’s lives as well) would be slightly easier if liquibase classes that model the change oriented information implemented java.io.Serializable