I wrote a novel at first but rather let me rephrase this into something compact for reading (hence the edit).

When creating a generic light management system for forward rendering (light lists per object, will do forward+ later), is it expected to actually create light sources for explosions and aoe effects that games can be rampant with nowadays?

I can't imagine creating all the GPU-side resources on the fly for a lot of flaming debris, spells etc. would be healthy for FPS. I'm mostly asking about viability of this approach vs bloom or another post processing step that would handle this cheaply.

Or do people practice having a limited, preallocated and preinitialized stash of buffers that is just reused when necessary? This would, I assume, especially be important if shadow maps were to be used for resulting point lights which could be especially costly to do on the fly if, for example, one would want to spawn several light sources as a result of an explosion spewing items on fire everywhere.

Basically, how to handle volatile light environments? I mostly worked with a few static lights so far so this is fairly new to me.

It depends of the lighting technique you use.
I don't know how AAA games do it, but you can use arrays of lights.
The number of max-lights in the arrays will vary depending of the limits of the API and the limits of the FPS/hardware.

Basically, you stack lights in the arrays until you reach the limits of the API or the FPS.

For example you are limited to how many resources you can read from inside a vertex shader. This means you can not read from 30 shadow maps from the same shader. Arrays of lights can contain 500 lights, but there are other limits.

The simplest example is, to give to the shader the arrays of lights positions and colors and the shader will apply them all. If not shadow mapping, just coloring the pixel, you can compute 50 and more lights at once. Inside the shader you iterate over the arrays of lights(position and color). You can tell the shader how many lights you have at every frame by parsing the number of lights inside a constant buffer. This is the simplest example that you can expand for your needs.

The limits for lights that throw a shadow are tighter. In practice, you would cast only a shadow coming from the Moon light and the rest will be simple lights that can be all of them computed in the same shader. Lights that cast a shadow are expensive. For a demo you can have various expensive lights, but for games i almost always see only one shadow casting light being used.

Or do people practice having a limited, preallocated and preinitialized stash of buffers that is just reused when necessary? This would, I assume, especially be important if shadow maps were to be used for resulting point lights which could be especially costly to do on the fly if, for example, one would want to spawn several light sources as a result of an explosion spewing items on fire everywhere.

This ^^^. We have fixed-size pools for things like dynamically-spawned particles, lights, and the shadow maps used by those lights. If those pools are exhausted the engine will start dropping things so that it doesn't crash, and we'll log warnings so that artists and designers can adjust their content as necessary.

+1 on fixed sized pools/ array of lights, and doing lots of management to make the most out of them (also forward rendering on my side).

Thanks everyone. I'll try to use a fixed amount bound to the GPU and see what happens then.