With SetSlabNumberOfSlices(n), vtkImageReslice must interpolate “n” slices and then combine them to create each thick output slice. So it is guaranteed to slow down by at least a factor of “n”, but it generally slows down even more than that.
However, since you are seeing a the time increase by a factor of 1000, I suspect that part of the slowdown is due to cache issues. So with the benchmark, try at least to run multiple times and take the average time. Also, you can try increasing n a little at a time to see if there is a certain n where things suddenly slow down due to running out of cache.
Also try the vtkImageSlab filter, which is much faster if you just want to generate thick slices in the X, Y, or Z directions.
1sec for resampling and averaging 40 slices sounds about right for average-sized medical images on average CPU.
On the other hand, resampling the same image on the same CPU in 0.001sec is most likely a measurement error (for example, it is possible that it is so fast because you have already computed the output before and you just retrieve it).
If you want magnitudes faster thick slab reslicing then you can reslice on the GPU, using volume rendering. However, it brings in a lot of complications, for example you need to get the whole volume on the GPU, you get the resulting image in the frame buffer (not in the pipeline), there might be limitations in scalar types, etc.