plists absolutely cannot contain arbitrary Objective-C objects. They support a subset of Foundation container and value types and are not extensible to contain other types.
Anyways, it’s definitely true that plists support a superset of the data types supported by JSON: plutil will not convert the Safari bookmarks file to JSON, for example.
So while it is true that you can use these tools to convert a Plist from a binary or legacy format to JSON or XML and back, there are no guarantees you’ll be able to understand what was written to the plist originally.
The plist format does not encode metadata describing itself in any common standardized way: it’s not a JSONSchema, an XML Schema or even a protobuf .proto file. A well-written plist can be as self-describing as JSON or XML, though the concept of a schema for plist files doesn’t exist as far as I’m aware, outside of how apps choose to serialize objects, that is. (The data structures an app uses could be considered a schema for a plist but it assumes the data structures themselves are versioned when they need breaking changes…)
https://developer.apple.com/library/archive/documentation/Ge... has an example of “stringly-typed” keys and values. There’s not much validation in a generic plist editor just as there isn’t validation in JSON or XML by default, but any app can add its own validation to ensure what it saves to a plist is something it can read later… that’s where the confusion over objects and codables comes in. If an app wrote the object to a part of a plist, it can thus de-serialize it from how it wrote it. If your app doesn’t understand another app’s plist, that’s pretty normal for complicated files or data kept by third-party apps. Few apps consider metadata and longevity when they write to disk, such that migrations are handled version to version as they need to, etc.