The critical difference between the two approaches is, that the one he considers to be the only correct way is imperative and yours is declarative.
Your approach explicitly declares rules, i.e. the rules of the grammar are (almost) directly encoded in your code, and the parser library automatically transforms raw input into parsed output, while taking care of state and other things that are hard to handle. Your code is written within one single layer of abstraction, which coincides with the problem domain: parsing. It's reasonable to assume parsec's correctness, which means the only room for error here is, that your grammar definition is wrong. But then again you have fully qualified rule objects and they are easily tested in isolation. Also it might be worth noting, that mature parser libraries ship with one important feature: error reporting. Decent error recovery when parsing went wrong is not trivial. As proof, I invoke PHP's parse error, unexpected T_PAAMAYIM_NEKUDOTAYIM :D
His approach manipulates strings, explicitly maintains state and lifts up the raw input manually to parsed input. You have to write everything yourself, including error reporting. And when something goes wrong, you are totally lost.
The irony consist in that the correctness of a parser written with your approach is relatively easily proven. In his case, it is almost impossible.
There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult.
C. A. R. Hoare
Your approach is the simpler one. All it precludes is for him to broaden his horizon a bit. The result of his approach will always be convoluted, no matter how broad your horizon.
To be honest, it sounds to me, that the guy is just an ignorant fool, who is suffering from the blub syndrome, arrogant enough to assume you are wrong and yell at you, if he doesn't understand you.
In the end however, the question is: who is going to have to maintain it? If it's you, then it's your call, no matter what anybody says. If it's going to be him, then there's only two possibilities: Find a way to make him understand the parser library or write an imperative parser for him. I suggest you generate it from your parser structure :D
Best Answer
My best guess is that the sentence in the Wikipedia article result from a misunderstanding of E. Visser work.
Grammars for scannerless parsers (i.e. grammars describing a language as set of sequences of characters instead as a set of sequences of tokens with the tokens described separately as strings of characters) tend to have lot of ambiguities. E. Visser paper Disambiguation Filters for Scannerless Generalized LR Parsers (*) proposes several mechanisms to solve ambiguities, one of which is useful for solving the dangling else problem. But the paper do not state that the precise ambiguity named "dangling else problem" is related to scannerless parsers (nor even that the mechanism is especially useful for scannerless parsers).
The fact that it proposes a mechanism for solving it isn't an implicit statement as another ambiguity resolution mechanism (operator priority and precedence) seems also totally unrelated to the scannerless nature of the considered parsers (consider for instance that those ambiguities can't be present in regular grammars as they result from nesting, while those handled by a longest match rule can).
(*) Which is probably the paper serving as base of the Wikipedia article on scannerless parsers even if they reference another one, also by E. Visser, Scannerless Generalized-LR Parsing.