IMNSHO, it's not the size of the code you copy, or the code's generality, that distinguishes between sloppy, dangerous cargo-cult programming and legitimate re-use, but how well you understand the code. (Sure, it's almost always better to generalize the code you want to copy and modify, make it a subroutine, and solve a whole class of problems -- I refer you to Perl's genesis for prior art -- but that's not so much the point here.)

In The Pragmatic Programmer, Hunt and Thomas talk about code "wizards" -- programs which take a rough specification and generate an application framework. This is classic cargo-cult programming, if taken the wrong way: you have a complete MDI interface before you, but you have no idea of how, or why, it works. You just fill in the templates and hope you don't clobber anything important. Hunt and Thomas suggest that the way to make wizard use healthy is to understand the code that gets produced.

So it's understanding that makes the difference between laudable re-use and cargo-cult programming. If I understand the code that I'm copying in, I'm fine. If I don't understand the how, but the code's in a library (or a module) and I grok the interface, then I'm fine using the module. (If I open it up and copy a likely looking function out of it, then I'm probably hosed.) If I don't understand even one line of it, but I use it anyways, and try to make the rest of that line's context look like the last place I saw it, then I've fallen into cargo-cult programming, and I deserve everything I get.