From my understanding the top color should have a minimal impact on the result for small values of top.A, or a zero impact if top.A == 0. Instead, in these cases top color values appear to be added to bottom color values.

Judging from my experiments with an LED strip, multiplying top color values with top.A seems to improve the result.

When comparing Color.Rainbow and Color.Spectrum using an LED strip,
I found that colors look quite dim when using the first function on the same HSV Color values.

This appears to be caused by a code sequence at the end of Color.Rainbow(), where color values get scaled down:

If, for instance, the V value of the original color was 80, the brightness of an RGB color calculated with Color.Spectrum will still be around 80. With color.Rainbow though, brightness will be around (80/255*80/255)*255 ≈ 25 only.
For an original Color.V value of 20, the color.Rainbow brightness will be < 2 (20*20/256).
See also this playground example: https://go.dev/play/p/i6Mi9ggVjq5

This behaviour appears to be implemented in FastLED already.
As a workaround, when using color.Rainbow, I'm multiplying the resulting R, G, B values
with 256 / V with V being the original Color.V value.
I guess it could be fixed by just deleting line 192, val = scale8_video(val, val), which would skip one extra multiplication with val. Since scale8_video only returns zero if both arguments are zero -- in this case, if val is zero --, deleting that line would preserve this feature.