Context: It is highly recommended to use a non-fast light stage (even if light bounces are fast) as it produces much better graphics, and current computers are fast enough to compute that, see for details: https://forums.unvanquished.net/viewtopic.php?t=2181
The q3map2 tool recognized the q3map_noFast option to force a given light shader to not be fast when the whole build was set as fast, but it lacked the q3map_fast option to force a given light shader to be fast when the whole build was set as non-fast.
Actually it doesn't really make sense for a new map to use a fast light falloff, but when rebuilding an existing map that was tested with a fast build, this may not give the expected results on some edge case. This situation is believed to be rare, but it can happen.
Here is an example of the hangar28 map for Unvanquished from 2017, the translucent force field dome uses a shader emitting some cyan light to pain the nearby surface as a special effect. It's a sci-fi effect and isn't meant to be physically correct:
When using a non-fast light falloff, the whole place is painted in cyan:
Using the q3map_fast option, we keep the special effect working as the mapper tested it:
I only expect this keyword to be used on things that aren't really lights but are implemented as light shaders as a way to intentionally bleed some colors. This is meant for compatibility.
First screenshot is using a fast build.
Second and third screenshots are using a non-fast build (they also use a more recent source directory, hence the difference due to normal maps). The third screenshot also uses q3map_fast on the force field shader to keep the legacy behavior of the emitted color.