There is one fairly obvious possibility (though because it is obvious doesn't mean it'll improve your performance much):

Remove one entire pass of the data by combining the map & grep:

push @lines, grep { /Running|Dump|FromCB|Update/o && filterLog($_) } <
+$fh>;
[download]

(And get rid of that & unless you know what it is doing!).

Beyond that, most of the possibilities lie inside your filter sub, but before dicking around with that, and in the absence of any easy way to test the changes, you are going to have to explain a couple of things.

1. unless ! exists $opts{'day'} || /^$opts{'day'}/o;

   That might be equivalent to if exists $opts{...} and $line !~ /^$opts{...}?

   But as you are not specifying $line, it is implicitly using $_; which may be the same thing but with your use of & on the call and my vague memory that it does something special (that I never use so cannot remember), I'm unsure quite what the final semantics of your double negative cond or cond is actually doing?

2. Same goes for the two similar expressions further down:

   return unless ! exists $opts{'start-time'} || $opts{'start-time'} lt $
   +1;
   return unless ! exists $opts{'stop-time'} || $opts{'stop-time'} gt $1;
   [download]

   I think those lines are equivalent to

   return if exists $opts{'start-time'} and $opts{'start-time'} ge $1;
   return if exists $opts{'stop-time'}  and $opts{'stop-time'}  le $1;
   [download]

   But without the ability to test it, I'm not 100% certain.

3. And while I'm at it, why are you using empty prototypes on subs which take arguments?

   sub mergeLogs() {
   sub filterLog() {
   [download]

   Do you know what those empty parens mean? Or what they do?

Assuming I've understood those compound conditionals, you might gain a little by recoding your filter sub to use $_ exclusively (and yes, it will send the critics into apoplexy :):

sub filterLog() {
    s/ {2,}/ /g;
    s/^((?:\S+ ){3}).+?\[?I\]?:/$1/;
    s/ ?: / /g;
    s/ ACK (\w) / $1 ACK /;

    return if exists $opts{'day'}  and not /^$opts{'day'}/o;
    return if exists $opts{'user'} and not /[\(\[]\s*(?:$opts{'user'})
+/o;

    if (exists $opts{'start-time'} || exists $opts{'stop-time'}) {
        if ($line =~ /((\d{2}):(\d{2}):(\d{2})\.(\d{3}))/o) {
            return if exists $opts{'start-time'} and $opts{'start-time
+'} lt $1;
            return if exists $opts{'stop-time'}  and $opts{'stop-time'
+}  gt $1;
        }
    }

    warn $line if $opts{'verbose'} > 3;

    return pack 'da*', ( $2*60 + $3 )*60 + "$4.$5" ), $_;
}
[download]

Update: Actually. if your original sort using cmp works, then there is no need to pack the date, you can just prepend it in its string form and the GRT woudl still work. You'd have to adjust the substr accordingly.

And look closely at that last (return) line and the date regex. I'm prepending the time (as a packed double) to the line. This would necessitate another change in the grep to assign the return value back to $_:

grep { /Running|Dump|FromCB|Update/o && ( $_ = filterLog($_) ) } <$fh>
+;
[download]

The benefit of this (assuming it works; this is all speculative--you'll have to test it), is that you can now avoid parsing the time twice, and the 'zillions of anonymous arrays' syndrome of the ST sort, and use a GRT instead:

    @lines = map{ 
        substr $_, 8 
    } sort @lines;
[download]

You don't say how much of the time is spent sorting, but that should reduce it.

My final speculation is that the bunch of modifications you make to the log lines at the start of the filter sub:

    s/ {2,}/ /g;
    s/^((?:\S+ ){3}).+?\[?I\]?:/$1/;
    s/ ?: / /g;
    s/ ACK (\w) / $1 ACK /;
[download]

in the absence of any actual data, don't appear to affect the filtration regexes. If that is true, and those manipulations are required for a later stage of the processing, then move them to the end of the sub so that you aren't making multiple passes of every line including all those you will subsequently reject.