Recently I've had to deal with an outbreak of issues with people having trouble with serialized data not working on newest versions of PocketMine-MP. While serialization may seem like a pretty nice simple way to store data that doesn't require more code, storing serialized objects is a very bad idea, because any changes to the classes you're serializing (which can happen any time in PM core!!!) WILL BREAK YOUR DATA. As an example, SlapperCache abused serialization to store CompoundTag and Item objects. Because these classes and their descendents subsequently changed in their implementations, the data stored no longer works after unserializing. As seen in the most recent commits, a whole bunch of ugly hacks were needed to try and salvage the data. TL;DR: Stored data depending on code is BAD. Do not abuse serialization. Your data storage format should always be independent of the code reading it. If it is not, it can and will break.
For the technical who want more detailed examples: - Serializing a "DiamondSword" object in ALPHA10 will now unserialize into a __PHP_Incomplete_Class because the "DiamondSword" class doesn't exist anymore - Serializing a CompoundTag prior to ALPHA11 (which used dynamic field assignment) will now unserialize to an empty CompoundTag with those fields assigned but ignored (because the internal implementation has changed).
If the class is changed in any way (for example extra fields added, changed or removed) or the class is deleted or moved or whatever, your serialized items will break.
Note: the DiamondSword problem is actually the fault of API change. But the Compound tag problem is related to changes in undocumented internals and is indeed a genuine problem of serialization.
regardless of who you blame, it is still very difficult to salvage data from a __PHP_Incomplete_Class.
It is ok as long as it doesn't contain non-stdclass objects inside. Just the ands data as those you'd store in YAML.