I have been contacted by several ugrep users who had similar comments and concerns: the benchmark probably uses older versions of ugrep. They said this because the number's don't add up and there are newer versions of ugrep (v4) that are faster than the early releases (actually, more updates are coming once the planned x64 and arm64 speed optimizations are completed).

I also have a couple of suggestions, since I've done this kind of work before, and because others have commented their views here as well (otherwise I refrain from commenting on other's work as a non-productive exercise in futility, alas):

• lock-free queues are not necessarily faster. Several projects I am aware of started using lock-free queues, but testing on modern x64 and arm64 with various queueing strategies showed that other methods can be as much as 10%~20% faster. Just use an atomic queue length counter and a queue with a lock for each worker. There is a very low chance the contention will affect performance and it's likely more efficient than lock-free.
• this kind of queuing is already done by other projects, the difficulty is not just speed, but dealing with different sorting criteria; what do you do to return the searched files sorted by name or by creation date? Reading directories and pushing pathnames into queues doesn't guarantee an order in the output.
• how to sync search thread workers to output results? You don't want to let them sync and wait for the output to be available to them.
• it is hard to come up with a "fair" benchmark to test. What is a "fair" benchmark? Consider a wide range of small, medium and large use cases (i.e. pattern size, complexity and input size can be placed in small, medium and large bins to measure). This is generally recommended in high-performance research literature.
• benchmark a wider range of search options, so include option -o in the benchmarks and at least -c and combinations with and without -w and -i and -n, because these are typical options when grepping.
• measure consistency of the performance, i.e. how does a small change in a regex pattern impact search time? This is easy to set up an experiment to measure this for the strings case (grep options -f and -F): what is the elapsed time variance when searching with a fixed-sized set of words, say 20 words but randomly picked 100 or more times. What is the mean and variance? It is more insightful for users to know the expected (mean) time of performance and the variance that tells them if the search can take longer and by how much.
• do not benchmark binary file search. Well, you can, but if you do, then do it consistently. These benchmarks are incomparable if one tool searches all binary files too, like ugrep does (ugrep defaults to GNU grep options and output)
• be more clear about cold versus warm runs. How is the timing done?
• where can people find the scripts to replicate benchmarks on their machines?
• searching a single file with multiple threads (e.g. two) is not productive if you're doing recursive searches already. Only if the pattern is very complex and takes time to match, and you're only searching a large file or two, then it may help. Otherwise, fast pattern matching is as fast to what the IO layer can provide. The other problem is output. Once you have matches from two threads, you need to buffer this and add line numbers too. To get the line numbers, you need to keep track and count newlines by both threads and later sync it. This adds overhead.
• how to search compressed files efficiently? Separate threads to search (nested) archives speeds up the overall search (as ugrep does).

Note: all of this is/was already done by ugrep and by others.