This from version 4 of the Internet Draft:

Note that the JSON representation does not use the "rel" or "rev"
constructs used by [RFC8288] and the above specified HTTP Link
document format. Rather:

o A link that uses the "rel" construct in those approaches is
conveyed using the URI of the link context as the value for
"anchor" and the URI of the link target as the value for "href".

o A link that uses the "rev" construct in those approaches is
conveyed using the URI of the link target as the value for
"anchor" and the URI of the link context as the value for "href".

Correct. However, RFC 8288 deprecates the rev parameter:

rev is deprecated by this specification because it often confuses authors and readers; in most cases, using a separate relation type is preferable.

So, it's inaccurate to say "the rel or rev constructs used by [RFC8288]" since RFC 8288 specifically deprecates the rev construct.

To acknowledge that fact, I was suggesting that the language from the draft that you copied here be removed.

Instead, I would add a scenario along these lines:

In some cases, it is useful that links are given both from a context resource to a target resource and also from the original target resource back to the original context resource. In other words, it can be useful to represent a bidirectional link.

In such cases, the first link can be serialized normally and the reversed link can be serialized by giving the URI of the original target as a link anchor and giving the URI of the original link target as the link href.