I suspect this is a case of premature optimisation, but assuming this really is a bottleneck, the biggest loss of time would be calling the Perl compare function repeatedly. Using a basic lexical or numerical sort would be better. (The default callback, { $a cmp $b } and { $a <=> $b } are handled super efficiently.)

use 5.010;  # say
use strict;
use warnings;

use Date::Manip qw( ParseDateString );

my @dates = (
   "Aug 8 12:12:13",
   "Jan 1 21:01:03",
   "Aug 8 12:12:14",
   "Aug 7 09:12:10",
);

my %lookup;
say $lookup{$_}
   for
      sort
      map { $lookup{ my $s = ParseDateString($_) } = $_; $s }
      @dates;
[download]

use 5.010;  # say
use strict;
use warnings;

use Date::Manip qw( ParseDateString );

my @dates = (
   "Aug 8 12:12:13",
   "Jan 1 21:01:03",
   "Aug 8 12:12:14",
   "Aug 7 09:12:10",
);

say substr($_, 16)
   for
      sort
      map ParseDateString($_).$_,
      @dates;
[download]

The following might be faster by taking advantage of internal optimisations.

use 5.010;  # say
use strict;
use warnings;

use Date::Manip qw( ParseDateString );

my @dates = (
   "Aug 8 12:12:13",
   "Jan 1 21:01:03",
   "Aug 8 12:12:14",
   "Aug 7 09:12:10",
);

$_ = ParseDateString($_).$_ for @dates;
@dates = sort @dates;
say substr($_, 16) for @dates;
[download]

I also agree with the previous comment about replacing ParseDateString with something tailored to your needs. Mind you, if you write the replacement in Perl and if ParseDateString is currently written in C, the replacement could easily be slower.

I haven't benchmarked anything.

If you are looking for speed, I'd recommend something like this (trading space for time + process your string using native functions):

my %h1 = (
    'Jan' => 'a',
    'Feb' => 'b',
    ...
    'Dec' => 'l',
);

my %h2 = (
    'a' => 'Jan',
    'b' => 'Feb',
    ...
    'l' => 'Dec',
);

my @sorted_dates =
    grep { s/^(.)(\d\d)/$e{$1} . ' ' . sprintf("%d",$2)/e }
    sort
    grep { s/^(.{3}) (\d\d?)/$d{$1} . sprintf("%02d",$2)/e; }
    @dates;
[download]

Of course you can/must rework the regex'es according to string format. Compared to code using Date::Manip, this one runs ~200 times faster (on my system)

EDIT: in regex'es $d must be $h1 and $e must be $h2

my %h1 = (
    'Jan' => 'a',
    'Feb' => 'b',
    ...
    'Dec' => 'l',
);

my %h2 = (
    'a' => 'Jan',
    'b' => 'Feb',
    ...
    'l' => 'Dec',
);

my @sorted_dates =
    grep { s/^(.)(\d\d)/$h2{$1} . ' ' . sprintf("%d",$2)/e }
    sort
    grep { s/^(.{3}) (\d\d?)/$h1{$1} . sprintf("%02d",$2)/e; }
    @dates;
[download]

grep? What are you trying to filter out?

Anyway, the following manipulations are twice as fast:

my %month_key_lookup = (
    'Jan' => 'a',
    'Feb' => 'b',
    ...
    'Dec' => 'l',
);

my @sorted_dates =
    map substr($_, 12),
    sort
    map { /^(.{3}) (\d?)(. .*)/s;
          $month_key_lookup{$1}.($2||'0').$3.$_ }
    @dates;
[download]

As a bonus, it doesn't clobber the contents of @dates.

#year-month-day with leading zero'es!
2010-08-06 13:12:13 # "Aug 6th, 2010 13:12:13" (1 pm+)
2010-01-01 21:01:03 # "Jan 1, 2010 21:01:03" (9 pm+)

A true defeatist would also note the time zone isn't specified either and that double-digit days aren't supported. This problem is truly impossible to solve!

++Re^4: sort based on date

Unless you know all the dates in the set are from the same year.

Put another way: unless you get the year into your dates, the year will get you just after new year.
Also, POSIX or equivalent ISO date format YYYY/MM/DD hh:mm:ss is the most portable and most universally understood (human or program), and also best defined for sorting or other date manipulations.
the hardest line to type correctly is: stty erase ^H

Unless you know all the dates in the set are from the same year.

Sure, but no such assumption was stated by the OP. An equally valid assumption would be "next occurrence" of the given dates - one might for instance have to order dates for soccer matches of the coming season.

My meta point of course is that if people post problems here, they shouldn't hide essential knowledge about the problem (I do assume the OP knows which years the dates are supposed to have).