In principle any character in a URI can be percent-encoded, and for unreserved characters the resulting URLs are equivalent.
Capturing this equivalence in the ABNF grammar (e.g. accepting "$f%69lt%65r" in addition to "$filter" would make it rather unreadable, so I propose that URLs must be percent-normalized before being run through the grammar, and call that out in a comment at the beginning of the ABNF rules.
A trickier problem is that not all user agents fully follow the rules in RFC3986. The characters "[", "]", "
{", "}", and DQUOTE (") are very important in JSON constructs and not percent-encoded by IE9, Chrome22 and Firefox15 when occurring in the query part, although RFC3986 requires it. Safari5 on the other hand correctly percent-encodes them.
The conservative choice for a normalization rule here would be that these characters are percent-ENcoded before applying the grammar to produce "legal" URIs. A more readable approach (at least for those test cases passing JSON constructs as parameters) would be to require percent-DEcoding for these special characters in the query part, which is unproblematic as they have no special meaning there.
If the latter, more readable approach is chosen, it could also be applied to SPACE and HTAB, resolving ODATA-127 on the side of readability.