In all of my days, I can only remember using pack() once in a production application. That's not because it's not useful; it's because I'm fortunate to deal almost exclusively in text in my work. I know I've used it in some tinier things but none come to mind.
Having little pack() experience, I find pack templates to be as incomprehensible as regexes to a VB programmer. Without online reference material I'd never have a chance.
So here's a thought: most uses of pack should be wrapped up in a small subroutine, shouldn't they? I mean, if you are unpacking a struct, make two routines (to convert either direction) that take binary data on one end and an array, hash, or object on the other. If you're performing some other conversion, say, converting epoch seconds to Julian dates with a brilliant use of pack that shaves
Sticking unexplained pack() calls right in the main code might be quick and easy, but think what you can gain with a well named subroutine with an obvious purpose that hides pack() away where you don't have to see it except when you want to. Think how you could write tests on just that subroutine. Think how the name makes the purpose clear. Think how the inexperienced programmer doesn't have to look up pack() if he knows he can trust that conversion routine. Think how you don't have to fool with it again if you know you can trust the routine.
Oh, I see to be gushing. I'm suddenly reminded of perlstyle:
Think about reusability. Why waste brainpower on a one-shot when you might want to do something like it again? Consider generalizing your code. Consider writing a module or object class. Consider making your code run cleanly with use strict and use warnings (or -w) in effect. Consider giving away your code. Consider changing your whole world view. Consider... oh, never mind.