But some parts, like e.g. the cut operator is something I've copied several times over for various things. A couple of prototype parser generators for example - allowing backtracking, but using a cut to indicate when backtracking is an error can be quite helpful.
That may make sense for Prolog code - I don't know Prolog enough to say. But the places I like to use it, it significantly simplified code by letting me write grammars with more local and specific error reporting.
That is, instead of continuing to backtrack, I'd use a cut-like operator to say "if you backtrack past this, then the error is here, and btw. (optionally) here is a nicer error message".
This could of course alter semantics. E.g. if I had a rule "expr ::= (foo ! bar) | (foo baz), foo baz would never get satisfied, whereas with "expr ::= (foo bar) | (foo baz)" it could. (And in that example, it'd be totally inappropriate in my parser generator too)
I'm guessing the potential to have non-local effects on the semantics is why you'd consider it problematic in Prolog? I can see it would be problematic if the cut is hidden away from where it would affect you.
In my use, the grammar files would typically be a couple of hundred lines at most, and the grammar itself well understood, and it was used explicitly to throw an error, so you'd instantly know.
There are (at least) two ways of improving on that, which I didn't bother with: I could use it to say "push the error message and location" and pop those errors if a given subtree of the parse was optional. Or I could validate that these operators don't occur in rules that are used in certain ways.
But in practice in this use I never ended up with big enough code that it seemed worth it, and would happily litter the grammars with lots of them.
I used to use a cut operator about every 2 to 4 rules. If you are constantly using it as error handling, I would agree you are using it too often. If you are using it to turn sets into scalars or cells, then you are using it correctly. It just makes the code really hard to reason about and maintain.
There was a time when the thinking was you can load all the facts into a prolog engine and it would replace experts like doctors and engineers - expert systems, it didn't work. Now its a curiosity