One health bar went red and took the rest with it

Two of those options keep the mutation and give each bar its own object to mutate. The third changes the operation. If the fill only ever has two looks, two stylebox resources that never change, assigned with add_theme_stylebox_override, mean no bar owns anything mutable and the sharing stops mattering.

Duplicating per bar is the better fit when the colour is continuous, a blend from green to red, where presets would multiply without end. So which is it showing, a threshold or a gradient?

The least code is a checkbox. Select the StyleBoxFlat in the inspector, open its Resource section and tick Local To Scene. Every instance of the bar scene then gets its own copy when it's instantiated, and your handler can stay as it is. I'd start there and only write something if it turns out not to be enough.

Watch get_theme_stylebox("fill"). Remove the override one day and it returns the theme's stylebox, and the handler recolours every ProgressBar on that theme. A duplicate() before writing covers both cases, and a shallow copy is enough for a StyleBoxFlat.

Before ticking it, it's worth checking where the stylebox actually lives, because Local To Scene acts on a resource the scene uses. Is it a built-in sub-resource of the bar scene, or a .tres file that the override points to? Either should get duplicated per instance, as far as I know. A stylebox that comes from a Theme on some parent node is a different object, though, and the checkbox on the bar's own override won't reach it. Once that's known, the checkbox is a safe first step.

Built-in sub-resource, saved right inside health_bar.tscn, no Theme anywhere above it. Ticked Local To Scene and it works, the damaged unit's bar goes red on its own and the others stay green. Slightly annoyed that it's a checkbox and not the default, but I get it, most styleboxes are meant to be shared and copying all of them would be silly.

Now I'm curious how many styleboxes exist. Print $Bar.get_theme_stylebox("fill").get_instance_id() from two bars in _ready. One number before the checkbox and two different ones after, if the copy happens where we think it does. Then try a bar added at run time with instantiate() instead of one placed in the editor, just to see whether it gets its own copy as well.

Why touch the stylebox at all? self_modulate is per node. Set it to red on the one bar and nothing is shared. Two hundred bars means two hundred colour values on two hundred nodes and zero extra resources.

Tried that first, it's how I ended up in the stylebox. self_modulate multiplies everything the bar draws, so the grey background turns dark red along with the fill and you can't read how much health is left anymore. Works for a quick flash on hit, not for a state that sticks around.

Presets get my vote too, though for a reason other than the object count. The rule worth keeping is that each bar's colour depends on its own unit's health and on nothing else. A shared mutable stylebox breaks it by letting one unit's health decide another bar's colour. Duplicates restore it, provided every copy is actually made. Two presets restore it without depending on any copy, because the handler picks one from the current value and the presets themselves never change. I'd still test the value 25 itself, since < and <= disagree there.

Printed the ids. Before the checkbox all six bars showed the same one, after it six different ones, and a bar added with instantiate() got its own too. So that worked as described.

Then I switched to two preset styleboxes anyway, mostly because of tally6's point. The handler is down to this.

const FILL_OK := preload("res://ui/fill_ok.tres")
const FILL_LOW := preload("res://ui/fill_low.tres")

func _on_health_changed(value: float) -> void:
	$Bar.value = value
	var fill: StyleBox = FILL_LOW if value < 25.0 else FILL_OK
	$Bar.add_theme_stylebox_override("fill", fill)

Local To Scene is unticked again, since nothing writes to a stylebox anymore. Still haven't decided whether exactly 25 counts as low.