Looks good. Note that there is a way to compute the min *and* max with fewer comparisons. No idea if this has any effect in runtime.

The basic idea to reduce comparisons is to (1) always process two elements together and (2) use the fact that we compute the minimum AND the maximum.

void compute_min_max_simple(float a, float b, float &min, float &max) {
  if (a < min) min = a;
  if (a > max) max = a;
  if (b < min) min = b;
  if (b > max) max = b;
}

void compute_min_max_new(float a, float b, float &min, float &max) {
  if (a < b) {
    if (a < min) min = a;
    if (b > max) max = b;
  }
  else {
    if (b < min) min = b;
    if (a > max) max = a;
  }
}

As you can see, in the new variant there are only three comparisons in every iteration, while in the first variant there are four.
No idea if this can actually improve performance. It could potentially make it much worse as well by reducing the effectiveness of cpu branch prediction. The conditions in the first algorithm are almost always false, making them easy to predict. In the second algorithm the first condition is much more random usually.
Could be interesting to try this at some point, just wanted to throw it out here :)

I noticed that in some test cases the execution time of the Bounding Box node is much slower than the actual call to BKE_mesh_minmax (400 ms in node, but only 60 ms computing the bounding box). In those cases the majority of the time is spend freeing the input geometry after the bounding box has been computed. Would be interesting to check if we could let another thread do the freeing in some cases.
An alternative would be to use get_input instead of extract_input when getting the geometry in this node. Then the node wouldn't be responsible for freeing the input geometry. That doesn't affect the actual run-time yet, but it could make the time reported to the user more useful.