Interesting viewpoint, A coder can only really be expected to understand and manage a finite number of lines of code.

So having abstracted the Programmer interfaces, which your helper functions really are will definitly help to limit your universe of code. As you point out this is espcially useful if the underlying implementation is some low level black magic that nobody needs to worry about. So generally if your helper functions relate to 3rd party libraries that you will not or cannot modify then you are ok.

For example I use many cpan modules and am lazy in that I have no clue how most of them work under the hood. If I tried to understand them all my brain would surely explode.

Now if I did have a problem or want to extend a cpan module I would check out the documentation/POD for it and speak to my colleagues, failing them then the author.

The same applies to you internally make sure these utility modules are well documented so that any coder can look into them.

As for what is in the modules it is a case of the level of control required and the amount/quality of each api exposed. Consider for your business and your programmers skill set which parts of the code are most important, sounds like you work with xml so maybe ensure all you coders know the basics of cpan xml modules