This is why @context exists. Travel in the ActivityStreams context document expands to https://www.w3.org/ns/activitystreams#Travel and refers specifically to the concept or notion of a Travel activity as defined by the Activity Vocabulary. If someone wanted to have different semantics for travelling, they can do that in a different vocabulary.
This is what you get “for free” with JSON-LD, and what you stand to lose by moving to “pure JSON”: a complete lack of context, and therefore a complete lack of decentralized extensibility. It also creates a VERY fragile handling of how to name any given property or class, because you don’t have anything else to work with other than a single unqualified bare string. You wouldn’t be able to tell if actor meant “an entity performing an activity” or “a person who played a performance role in a movie”. You would suddenly need a central body to decide which use of the term actor is “correct”, and they would have to decide to potentially rename terms to resolve this ambiguity, which would break all existing implementations.
Or, the much simpler solution ahead-of-time is to be unambiguous with what you meant in the first place. You and I should both know exactly what is meant by https://www.w3.org/ns/activitystreams#actor versus what is meant by http://schema.org/actor. The @context mechanism in JSON-LD allows you to not have to type out the whole IRI every single time, using your own mapping of terms as you please. And the wonderful thing is that it’s possible that you and I don’t need to agree to use the same context – I can use a context that maps doer to https://www.w3.org/ns/activitystreams#actor, and you can use a context that maps as2_activity_performer to the same IRI. Expanding the term to a full IRI should arrive at the same IRI, and thus we know for sure that we both meant the same thing.
The juggling act that the Activity Streams 2.0 spec had to do is to decide that the AS2 vocabulary reigns supreme, that AS2 documents “MUST NOT override or change the normative context.” This is what makes the “plain JSON” interpretation of AS2 possible, but it also means that using shorthand terms for extensions is suddenly much more difficult than it needs to be. You end up with a problem where, for best results, two people need to agree to use exactly the same context, otherwise their extensions will not match in shorthand. The only way around this is to generate your AS2 documents with full IRIs always, or otherwise you expect that any “plain JSON” consumer shares the same context. (For more about this specific issue, see FEP-e229: Best practices for extensibility for further discussion.)