Time and time again I am stumped by the following
problem: WHEN do I stop helping ? when is it enough, when
do I get the feeling I`m taking over their code ?

...

Don't get me wrong here, I really try to explain the
problem with their code, and the reason why I would do it
differently. But these people aren`t coders, they`re
application managers, writing little tools to make life a
little easier on themselves.

As I see it, there are (at least) two ways of looking
at your problem: the pedagogical ("How do I best teach
these people?") and the business ("What's the best way to
get the job done?"). (I'm an academic, basically, so I
like the first one, but YMMV.) Which way you want to look
at the problem is going to affect whether you step in and
write someone else's code.

If you're trying to teach someone, it's probably best
to get them to code as much as possible, and write code
"for" them only to illustrate a new point, or to provide
a framework for what they're doing. (For instance, in a
machine learning course I took a couple of years ago, we
were handed most of a neural networks package fait
accompli. Our task for that assignment was to write
the backpropagation code, not the framework.)

In a business context, things get more complicated. It
might easily be worth your while to write a few little
tools for these managers, especially if they're trivial
(to you) scripts that you can toss off in ten minutes, but
that take the managers hours to produce broken code. In
that case, it's far better to take ten or fifteen minutes
of your time than it is to take two or three hours of
theirs, and get a better result.

On the other hand, teaching these managers the basics
of good programming might be spectacularly worthwhile.
One thing I've noticed about programmers (mostly myself)
is that as we learn, we spend more time coming up with
ways to get the computer to do our work for us. (Start
with code to solve tedious problems, then code to write
tedious code, and so on.) Getting consultants and
managers to think in terms of automating tasks, and to
push the boundaries on what they consider automatable,
might be a huge win. In that case, you'd be better off
taking a more pedagogical approach.