I'm very surprised at your results!

T::Q::A is a subcless of T:Q, so it does everything that TQ does, and some extra stuff on top, so how can it be quicker?

Especially as the 'extra' it does is to serialise the data passed into a mod//Storable::Freeze bytestring when enqueuing and unfreezing when dequeing. Neither of which is know to a an especially fast operation.

What puzzles me even more is that your benchmark is broken:

    if($test_queue_any){
      $queue_any->enqueue(%rec);
    }else{
      $queue->enqueue(\%rec);
    }
[download]

For TQA,

1. you're passing the hash as a flattened list; $queue_any->enqueue(%rec);
2. which internally becomes the array @_;
3. which is then converted to a single (freeze) string;     shift->SUPER::enqueue( Storable::freeze( \@_ ) );
4. and push onto the TQ queue proper.
5. At the other end a single string is read off the queue;
6. thawed back to a flat list and return to the caller; @{Storable::thaw( shift->SUPER::dequeue )};
7. where you reconstruct a hash from the list: while(my %hash = $queue_any->dequeue()){

For TQ, you queue a scalar (reference) directly to the queue, and the return that reference to the caller.

So both exchange a single scalar between the threads, but one does it directly; the other indirects through a subclass and flattens, freezes, thaws and reconstructs the hash on the way through.

How could the latter possibly be faster?

How could it possibly show fewer lock states--since the exact same underlying code is being used in both cases?

So I ran you code and got:

C:\test>TQ-TQA-b.pl
START LOAD 1
START LOAD 2

...

START LOAD 15
START LOAD 16
START WORKER 17
START WORKER 18

...

START WORKER 31
START WORKER 32
STOP LOAD 6
STOP LOAD 1

...

STOP LOAD 12
STOP LOAD 16
STOP WORKER 23
STOP WORKER 19

...

STOP WORKER 20
STOP WORKER 26
------------------------------------
TEST QUEUE:15(seconds)
------------------------------------
Enter an key to continue...

START LOAD 33
START LOAD 34

...

START LOAD 47
START LOAD 48
START WORKER 49
START WORKER 50

...

START WORKER 63
START WORKER 64
STOP LOAD 33
STOP LOAD 35

...

STOP LOAD 48
Odd number of elements in hash assignment at C:\test\TQ-TQA-b.pl line 
+80, <STDIN> line 1.
STOP WORKER 58
Odd number of elements in hash assignment at C:\test\TQ-TQA-b.pl line 
+80, <STDIN> line 1.
Odd number of elements in hash assignment at C:\test\TQ-TQA-b.pl line 
+80, <STDIN> line 1.

...

Odd number of elements in hash assignment at C:\test\TQ-TQA-b.pl line 
+80, <STDIN> line 1.
STOP WORKER 53
STOP WORKER 63
------------------------------------
TEST QUEUE ANY:20(seconds)
------------------------------------
[download]

Besides the warnings, which are essentially trivial compared to the other brokeness of the benchmark--more a sign of your lack of understanding of hashes than a serious problem--I get TQA taking 33% longer than TQ; which gels with my expectations!