I like the direction this draft is going. For this section, maybe the advice could mirror the AS2 Core recommendation to assume the normative AS2 context if it’s not included in the @context (versus ignoring context completely).
AFAIK, Mastodon requires the normative context URL to be in an AP activity @context or it will consider the activity to be invalid. If that’s correct, this unnecessarily reduces interoperability with conformant AP/AS2 publishers (that might not include any @context and use the AS2 content type instead). This isn’t a comment about your draft, but I wonder how developers can be convinced to change their implementations to use this practice.
It might be useful to organize the practices by publisher/consumer roles. For example, the recommended practice for producers might be to always include the normative context URI and for consumers to not assume it is there when an AS2 content type is used.
Would it make sense to include advice for documenting extensions (structure, behavior, required/optional properties, functional/nonfunctional properties, cardinality, valid value sets/enums, etc.) and for versioning extensions?
The advice for partially compacted terms is not bad, in general, but if someone followed that advice today (e.g. for the ubiquitous toot context), most servers would not accept the messages.
Even just a categorization of informational versus “spec/rec track” (the latter being part of your process substrate recommendation) would be useful. I think informational FEPs should typically never become FINAL in the way the FEP process defines that state.