That avoids naming conflicts, though it's a bit heavy-handed. And even in this case it's not true of all variables you're using, e.g. mark has potential to collide. (BTW: At one time, Ren-C took MARK as a keyword, previous to the new design for pos: <here> as how to mark series positions.)
In any case...my point stands, that you likely only intended here to bind rules parser. Yet with the historic workings of MAKE OBJECT!, when you do this with a COMPOSE and the block becomes a child of the object body, you will get the additional bindings of name, suffixes, identify?, rules, options, decode, encode... etc. Imagine adding mark to this list in your example...the user code bound to it could wind up corrupting state it wasn't supposed to see.
When people make these little "parse machine" snippets, I'd imagine they'd like to be able to take for granted that the parse machine engine could interpret those snippets without having to be given all of them up front in a block. Especially if the snippet might be generated dynamically. It would be nice if you could be on more of an even turf with the keywords of PARSE in this respect.