With INTEGER! being a combinator that just evaluates to itself, it permits us to have a fairly literate SKIP combinator:
>> parse [a b "Much more literate!"] [skip 2, text!]
== "Much more literate!"
Actually makes sense...as opposed the historical 2 skip. That required you absorbing that SKIP is an arity-0 function which you sometimes use to match ANY-VALUE! for SET rules... as well as that integers prefix a repeat count of the rule after it. Much clearer to say SKIP is a combinator that takes how much to skip!
Furthermore, per a thought from @IngoHohmann, it can have ELIDE-like behavior...which looks like a reasonable choice:
>> parse ["SKIP can return nihil!!!" a b] [text!, skip 2]
== "SKIP can return nihil!!!"
So the exception I've found here is byte counts when parsing binary. Things that know how many bytes they want literally put those byte counts down.
But where I once did copy 2 skip in these cases, that had become across 2 <any>. But rather than robotically turn that into across repeat 2 <any> this just needs to go back to across skip 2.
Yet in truth...these cases all tend to suck...and what they actually want is something like @rgchris's BINCODE, or ENBIN/DEBIN combinators. So I wouldn't have worried about it anyway.