They immediately become obvious as soon as you have a conflict in term names. How do you propose resolving naming conflicts without a central authoritative body?
If you wanted to avoid complexity but retain an unambiguous representation, then you would use JSON-LD expanded form instead of compacted form. Yes, you lose human readability, but you also completely eliminate the need for @context. It looks like this:
{
"@id": "https://domain.example/some-actor",
"@type": ["https://www.w3.org/ns/activitystreams#Person"],
"https://www.w3.org/ns/activitystreams#name": [{"@value": "Alice P. Hacker"}],
"http://www.w3.org/ns/ldp#inbox": [{"@id": "https://domain.example/some-inbox"}]
}
so it’s more verbose, but also in some ways simpler – you know exactly what is an ID and what is a Value, you avoid naming conflicts by namespacing your IRIs, and so on.
The primary reason compacted form exists is to “upgrade” plain JSON documents into JSON-LD. Say you have an API that already returns shorthand terms for JSON property names. Rather than converting your entire API to use IRIs everywhere (and breaking all existing consumers), you can just add one more key: @context. IMO, compacted form shouldn’t be used when designing a data interchange format from scratch. It only really makes sense when converting JSON to JSON-LD. The space saving you get from compacting your JSON-LD document against some context is real, but it’s not significant compared to just gzipping everything. And IMO, it introduces more problems when you hide the reality of the system from the users and developers, which I consider “necessary complexity”. It also introduces the possibility that a single attribute or property can suddenly be represented by infinitely many string keys, because that’s what “context” is and what it implies – reconciling different terms for the same thing.
The AS2-Core spec chose to hide this “complexity” by mandating that everyone just use the AS2 context and to not override it. They probably did this because they wanted the JSON of AS1-JSON to be cleanly migrated to AS2, and they thought developers would think that the compacted form is “prettier” or otherwise easier to parse visually and to understand as a human reader. It certainly makes examples easier to follow! But it makes actually working with the data harder than it needs to be once the natural complexity starts creeping back in. Suddenly you need to understand JSON-LD concepts like “context mapping” and “expansion” at minimum. If AS2 had gone with expanded form instead, you could still parse it as plain JSON, just that the parsing would be a bit more roundabout – to get the inbox of a person, you wouldn’t be able to do it via the inbox property’s value, you’d have to get the http://www.w3.org/ns/ldp#inbox property’s value which is an array, and then grab the first item out of the array, and then get the @id property’s value from there. So it’s less direct, but more importantly, it’s completely unambiguous what you ended up with. You don’t need to look in the @context to see that inbox is actually http://www.w3.org/ns/ldp#inbox, or that the @type of its value is @id. You already have that information ahead-of-time.
This is just JSON-LD with extra steps.