FWIW I'll chime in with my US$0.02 worth....

How far can you go with these helper functions before they hurt more than help?

The answer is: it depends. I've seen some extremes here in my travels about the industry. In one shop I worked in my job was to take the code that "low talent" programmers wrote and make it actually work. They had lots of helper code out there to help them to the point that all they really needed to do was cut/paste and put in some glue code to produce a working application. In spite of that they failed to produce working code about half the time and code that behaved in expected ways about 60% of the time and nearly all if it had bugs and/or security holes big enough to drive an SUV through.

Another shop I worked in had their data objects, stored procedures and such all well defined in an API such that writing code there from inception to working prototype had a very short time frame. Given the business environment this gave the company a very huge competitive edge that they leveraged off of every chance they got.

Yet another shop it was every person for themselves and each developer had a piece of the project and worked on it independantly with no one person driving the overall design. The term "1000 monkeys with typewriters attempting to produce Shakespere" used to run through my mind there constantly. As can be expected they had issues itegrating the individual modules that each developer was developing independantly from the other and getting the end (?) product to work.

So... the official answer is: it depends.

Whatever helper functions get developed need to fit within an overall architecture and need to be well documented.

How can you keep your developers on the ball in using these functions and in keeping the functions up-to-date? Can you simply chalk this up to 'make good documentation'?

Code specifications, having an overall code architect that sets direction, peer review and taking care to develop helper functions that are well documented, flexible, can be extended without modifying the "original" and taking care not to go too overboard that you squelch creativity as well as flexibility in your development environment.

On the other hand, what is a good marker for what should be in helper functions and what belongs in tighter control and usage?

See above. I have worked places where there was too much rigidity to the point where I had to get all sorts of sign offs and go through bureaucratic hoops to introduce a new Perl module either from CPAN or of my own authorship to places where it was total anarchy. Neither extreme makes sense. Finding the "sweet spot" requires effort up front and constant review and an occasional reality check to make sure your not going too far or being too lax.