Automation can never hurt, but it is never a replacement for real human testing.

As a general statement: you're of course right, but automatic testing is a real help in focusing your manual testing on broken things while fixing them. If we had a test-suite for the part I enhanced, I had noticed I broke it, and had a clear indicator as to where to look; we have automated builds in place, that inform you of errors/success in building a clean, freshly checked out version after you checked in new code (builds are done every ten minutes, if necessary); we should strive to do testing there too.

It depends on what kind of code you write, I guess, but in my case (at least), I see a lot of code (not just Perl) that does not fit cleanly into automated test frameworks.

This is the case here too with nearly all "legacy code"¹; you write different code, if you write with automated tests in mind; but I think this is a GoodThing(tm) -- and we should at least try to get to a point, where newly written code could be tested...

know when to use automated testing, as well as when automated testing is not the only solution. Obviously having an organization that doesn't agree to spend cycles in Q/A is a bad one in need of fixing!

Obvoulsy right :)
See my update to the OP; we will see if we can agree to something to assure more quality...