They will be storing ActivityPub data associated with a tag performing the role of an ActivityPub actor. I don’t need any serialisation to any parts of the client in discourse/discourse. The user won’t see this data in any part of the normal discourse/discourse client. The data will be serialised to the admin client, along with other data, however that is managed by the plugin in dedicated plugin admin routes. As you say, serialisation in the existing discourse/discourse tag routes (or the site serializer) would be tricky, for various reasons and not something I want to attempt, which is why I didn’t add preload or editable api methods.
In addition to having a stable api to work with, the reason they’re preferable in the ActivityPub plugin is because the plugin stores ActivityPub activities in a separate set of data models, the discourse_activity_pub_* tables, which then integrate with discourse/discourse via the defined plugin apis and core model’s custom fields. There is some intentional redundancy here to ensure proper separation of concerns between Discourse and ActivityPub data. As Discourse and ActivityPub have series of interrelated, but different, concepts and data models, keeping a clear distinction between ActivityPub data and discourse/discourse data is necessary to retain some clarity (and sanity) in what is a large and complex plugin. Using custom fields as an integration point is quite useful in keeping that separation clean and stable.
There is a brief explanation of this in the plugin’s readme.