There is the ability to add a fall back to the old behavior by replacing things like

if ((time_dt() - state_.start_render_time) < 1) {

with

if (((time_dt() - state_.start_render_time) < 1) || num_rendered_samples < 4) {

This fall back to the old behavior will result in faster viewport updates for scenes that render slowly.

For example, if a scene take 8 seconds to reach 5 samples, the fall back will result in faster viewport updates (in the specific scenario described, the viewport could update 1.75 seconds faster).

A fall back for the denoiser would also need to be added?
Something like this maybe? (I'm not sure if some of these brackets are necessary)

delayed = ((((time_dt() - state_.start_render_time) > 4) && (num_samples_finished >= 20)) && (time_dt() - state_.last_display_update_time) < 1.0);

Also, adaptive sampling is unaffected. I'm not sure how to change this.

I've done some further investigation and realize some of what I said in the previous comment is incorrect. The change to accommodate pixel size into path_trace_time_ might have to be made in /intern/cycles/integrator/path_trace.cpp

However, accommodating pixel size in path_trace_time_ will lead to issues else where.

  if (render_time < 1 || num_rendered_samples < 4) {
    return 0.1;
  }
  if (render_time < 2 || num_rendered_samples < 8) {
    return 0.25;
  }
  if (render_time < 4 || num_rendered_samples < 16) {
    return 0.5;
  }
  if (render_time < 8 || num_rendered_samples < 32) {
    return 1.0;
  }
  return 2.0;
}

I've had a thought about this part, specifically the num_rendered_samples < Y. I implemented it based on an idea that turns out to not be true upon further investigation of the code.

As a result
render_time < 1 || num_rendered_samples < 4
render_time < 2 || num_rendered_samples < 8
render_time < 4 || num_rendered_samples < 16
are basically useless. render_time < 8 || num_rendered_samples < 32 on the other hand does still help but only in a little bit.

I had questions relating to this. Since the first three options are basically useless, they have been removed. But should I also remove the last option?
For the last option is only useful in a specific situation. When you're rendering less than 4 samples per second and more than roughly 1 sample per second (I've had trouble with doing the math on this and I'm not actually sure what the minimum value is). If you meet that criteria, then display updates can be faster up to the 32nd sample when compared to removing num_rendered_samples < 32. I believe this is good because getting quicker feedback during these low sample counts is important, but if that is justification for this, then I could move the num_rendered_samples < 32 check onto the render_time < 4 line.

Adjusting the values for render_time < X and num_rendered_samples < Y and the return Z values will also change how useful these values are. However this might be outside the scope of this patch. There is a TODO earlier within the file with regards to tweaking these values for the best results:

Line 604
TODO (sergey): This is just a quick implementation, exact values might need to be tweaked based on a more careful experiments with viewport rendering. */