They're not "static enough" to have automatic serialization/deserialization and object inspector-like functionality. AFAIK in OpenStep/GNUstep/Cocoa objects (derived from NSObject) are expected to implement encodeWithCoder and initWithCoder to save/load to an object to disk and relies on per-class versioning and the subclasses handling the versions manually. The default NSObject implementation does not do anything as it doesn't have enough information to do anything "automatically". For an IDE you could have objects implementing a protocol that enumerates properties (or just creates the GUI for editing an object) but this isn't something that can be done by what the language provides itself.
In Smalltalk you might be able to inspect objects and their values. The VM certainly has enough information for that - after all it needs to so it can read/write the image the objects are in - but i don't know how much of that is exposed (i've only played around with a few Smalltalks and never made any real application with them). Though even if that functionality is available, you'd still need some way to tell -say- a Delphi-like object inspector what properties are available and what values they are meant to be (so, e.g., a "backgroundColor" property is presented in the GUI with a color editor and not a string editor or whatever else :-P).
In contrast, Free Pascal (and Delphi) has enough functionality to implement serialization/deserialization for objects without the objects themselves having to have any custom logic (this is how components are saved - you simply declare a published property and the framework handles serialization and the IDE handles showing it in the object inspector with the appropriate editor based on its type). In addition the on-disk format can be implemented in a way as to allow only storing properties which have different values from the defaults (there is a language keyword to specify what the default is though there are also other means), meaning that any new property can be added. The default object writers work like that but as this information can be exposed to any program, you can do your own (the default formats and functionality mostly support whatever is needed for saving GUI forms but in my own game engine i need more functionality than that to handle binary data and external data assets so i wrote my own serialization system).
In Smalltalk you might be able to inspect objects and their values. The VM certainly has enough information for that - after all it needs to so it can read/write the image the objects are in - but i don't know how much of that is exposed (i've only played around with a few Smalltalks and never made any real application with them). Though even if that functionality is available, you'd still need some way to tell -say- a Delphi-like object inspector what properties are available and what values they are meant to be (so, e.g., a "backgroundColor" property is presented in the GUI with a color editor and not a string editor or whatever else :-P).
In contrast, Free Pascal (and Delphi) has enough functionality to implement serialization/deserialization for objects without the objects themselves having to have any custom logic (this is how components are saved - you simply declare a published property and the framework handles serialization and the IDE handles showing it in the object inspector with the appropriate editor based on its type). In addition the on-disk format can be implemented in a way as to allow only storing properties which have different values from the defaults (there is a language keyword to specify what the default is though there are also other means), meaning that any new property can be added. The default object writers work like that but as this information can be exposed to any program, you can do your own (the default formats and functionality mostly support whatever is needed for saving GUI forms but in my own game engine i need more functionality than that to handle binary data and external data assets so i wrote my own serialization system).