I suggest that “the queued version,” as presented, is “intimidating” merely because it is very terse.   (It is, so to speak, “Perl golf.”)   The essential idea is actually simple:   a worker-thread survives for a long time, retrieving units-of-work from some thread-safe queue and executing them ... of course within an eval {..} block so that the thread will survive even if the unit-of-work does not.   The number of workers, of course, determines the number of units-of-work that this system will attempt to carry out at any one time.   The number of workers (just like the number of people who are scheduled for a shift at McDonald’s ...) should be “a knob” that is easy to set.

Perl has an interesting implementation of threading ... you need to look at the various docs (and here in PerlMonks) on that subject.

Now, before you proceed, you should also step back and be sure that you have reasonable cause to believe that “multiple threads” will, in fact, “be likely to make this operation run faster.”   Previous entries in this thread talk a great deal about this.   One “cheap and dirty” way to explore it is to launch multiple copies of this Perl program ... as it is right now (single-threaded) ... in separate terminal-windows.   Just how many windows can you have open-and-working at the same time, and still find that each of them finishes at about the same time?   (The time commandname command in Unix/Linux can give you hard numbers.)   If you find that “two windows equals twice-as-long,” then you can immediately conclude that mutlithreading would probably be a waste of time.   On the other hand, if you find that multiple windows do let you get the work done (across all windows) in about the same amount of time, then, well-l-l-ll... guess you have two choices!   One is to dive into multithreading as described.   Another is to ... “just run it as-is in multiple terminal windows!”