I see what you're trying to do, but I'm not convinced that this has any benefits (User or CPU wise). We are talking nano-seconds here.
At some point having as many tasks as threads can work against you. Adding additional tasks (like the before situation) might be more flexible during balancing.

In D11450#293159, @Jeroen Bakker (jbakker) wrote:

At some point having as many tasks as threads can work against you. Adding additional tasks (like the before situation) might be more flexible during balancing.

I'm not sure I understand.
The number of threads is the same.
extract_range_num_threads_estimate uses CHUNK_SIZE to define how many threads should be used (maybe the name can be improved).

What this patch does is distribute the elements more evenly.
To illustrate, the distribution of geometries can currently be described as follows:

thread 1: [60 polygons]
thread 2: [60 polygons]
thread 3: [3 edges]

With this patch these same elements are distributed like this:

thread 1: [40 polygons + 1 edge]
thread 2: [40 polygons + 1 edge]
thread 3: [40 polygons + 1 edge]

or

thread 1: [60 polygons + 2 edges]
thread 2: [60 polygons + 1 edge]

Due to recent changes is this still something we would want to integrate?
IMO the threading is good enough. Not sure if this fits in the parallel range implementation we have now.