I don't think this is an ill-considered question at all; in fact I'd say it's rather an interesting one, particularly the issue of why using separate packages might be a good thing. So no need to beat yourself up, I think. ;)

On the question itself: one simple reason might be that you intend to write some code that you're going to let other people use, maybe you'll be uploading it to CPAN, and you want to let other people use some particular function while not cluttering up their namespace, or getting them involved with other bothersome details of your module.

For example: I just needed to round a number to the nearest integer. I'm using a CPAN module which someone else has kindly written, called Math::Round. All I need to know about it, really, is that it adds two function names (it 'exports' them), 'round' and 'nearest', so I can't have a function with that name. I don't need to know (for example) that it uses a variable called $halfhex - and in fact I didn't know that until I just looked for an example. ;) If I already had a variable in my script called $halfhex, that wouldn't be a problem.

So anyway, it should be pretty obvious that this is a similar kind of thing to making variables local to a particular function, so they can't get messed around with elsewhere in your script.

The more general issue, and (I think) the particularly interesting point behind your question, is why this is a good idea.

There's some useful text at Wikipedia on Separation of concerns, Orthogonality and information hiding. Essentially the point is to keep parts of the program which do separate things as separate from one another as possible, to avoid screwing up one one of them when you're working on the other.

The principle is that it's easier to keep track of what you're doing if your actions are limited to one particular area, and don't have consequences outside that area.

An analogy that I've seen used is between the control of a helicopter, where moving each of the main controls requires a simultaneous matching move to the other controls to keep the aircraft stable, versus controlling a plane, where it's possible to change (for example) the direction of the plane without making changes to the power being used. The point being that controlling a plane is (apparently!) easier because the controls can be used 'orthogonally' from one another.

There's a good essay in 'The Mythical Man-Month: Essays on Software Engineering' (ISBN 0-201-83595-9) which talks about this in more detail, I think. If you hunt about a bit you should be able to find some OO texts dealing with the reasons behind encapsulation, too.

HTH!

Best wishes, andye

Update (2007-04-23): My book reference was wrong, I was actually thinking of 'The Pragmatic Programmer', ISBN 020161622X, in which the authors explain their analogy far better than I did:

A Nonorthogonal System

You're on a helicopter tour of the Grand Canyon when the pilot, who made the obvious mistake of eating fish for lunch, suddenly groans and faints. Fortunately, he left you hovering 100 feet above the ground. You rationalize that the collective pitch lever controls overall lift, so lowering it slightly will start a gentle descent to the ground.

However, when you try it, you discover that life isn't that simple. The helicopter's nose drops, and you start to spiral down to the left. Suddenly you discover that you're flying a system where every control input has secondary effects. Lower the left-hand lever and you need to add compensating backward movement to the right-hand stick and push the right pedal. But then each of these changes affects all of the other controls again. Suddenly you're juggling an unbelievably complex system, where every change impacts all the other inputs. Your workload is phenomenal: your hands and feet are constantly moving, trying to balance all the interacting forces.

Helicopter controls are decidedly not orthogonal.

Footnote: Helicopters have four basic controls. The cyclic is the stick you hold in your right hand. Move it, and the helicopter moves in the corresponding direction. Your left hand holds the collective pitch lever. Pull up on this and you increase the pitch on all the blades, generating lift. At the end of the pitch lever is the throttle. Finally you have two foot pedals, which vary the amount of tail rotor thrust and so help turn the helicopter.

(pp. 34-35)

It goes on to talk about the specific benefits that can arise from orthogonality: easier code re-use, easier for different team members to work separately on separate parts of the project, easier testing, less tie-in to specific platforms (e.g. our DBI module helps us to write Perl programs which are fairly orthogonal in respect of the database used), resulting code less fragile.