Where do you stop needing to understand what you're doing?

Once again, there's no pat answer. It depends on what you do with the code.

For a script you don't plan to use often, or for anything critical, you don't have to dig very far. Your code can be as sloppy(1) as you want it to be, because you're willing to accept the consequences, and you're not foisting them off on anyone else.

(1) - I don't mean to suggest that 'sloppy' is inherently bad. All code exists on a scale with 'sloppy' at one end and 'obsessive' at the other. A script that's 90% sloppy is still 10% obsessive, and one that's 90% obsessive is still 10% sloppy. Part of the programmer's job is deciding where on that scale each project should fall.

If you intend to use your code a lot, or to publish it for others to use, I personally think it's polite to shoot for the 'obsessive' end of the scale. At very least, you should work to avoid problems that are known and understood.

Implicit dependencies are a known, well-understood problem. Windows users have lived in 'DLL Hell' for years, and Linux developers have reinvented that same, butt-ugly wheel for themselves. Everyone wants to use libraries, but nobody can agree on which version of any given library to use, and the installers will happily replace some item 5 layers deep with another, possibly incompatible version.

Anyone who knows Open Source knows that large-scale coordination is one of the weak points of OSS development. Anyone who knows game theory knows that environments like that are fertile soil for yet another version of DLL Hell. The way to avoid creating a Perl version of DLL Hell is for each developer to be properly Lazy, and eliminate as many dependency problems as possible themselves, so people down the line won't have to.