Apologies if this comes across as nit-picky. I'm just trying to understand how things work.

You already have a filter for script.on_event calls. Why check a second time inside the method bodies themselves? If event.entity.entity.name == "spoilables-freezer" was going to fail, it would have failed at the event listener stage and the method wouldn't have been called in the first place.

Also, your event calls define a function within the scope of the listener that just calls another function with the same name outside of its own scope. Why not call the function directly? Say, something like...

script.on_event(defines.events.on_built_entity, on_built(event), event_filter)

You'd avoid needlessly generating a lambda function which serves no purpose. I don't know if this has a measurable impact, just curious, is all.

The second check is to allow expansion:

local event_filter = {
    {filter="name", name="spoilables-freezer"},
    {filter="name", name="cargo-wagon-freezer"},
}

local function on_built(event)
    local entity = event.entity
    if entity.name == "spoilables-freezer" then

    elseif entity.name == "cargo-wagon-freezer" then

    end
end

The filter causes on_built to only run in these two cases. Then I am going to deal with exact cases with if statements. (yeah, hashmaps blabla tables are better if there are many entities)

The lambda is how im used to writing, but yes, the other way is more concise.

All in all, these are player build listeners, they don't run by themselves.
They might be only ran 100 times in the whole game, so the performance is not critical, no need to do premature optimization.
Optimization of other functions like run on_nth_tick is a priority.

Understood. Thank you for the response. I'm still learning Factorio modding, so peeking under the hood of mods I download is always fun. Your reasoning here makes sense, within context.