If we consider for-loops as nested blocks of code, I thought the closest equivalent for node graphs would be subgraphs with dynamics in/out ports, but I imagine there must be a reason if Houdini doesn't do it that way?

I mentioned Houdini because it has become my go-to reference when it comes to node graphs. Worth checking for ideas!

When it comes to math graphs, these often end up looking like a mess of spaghetti that are difficult to reason about, so having a dedicated node for each op at least helps a bit to see what they do just from their type name, instead of needing to select/zoom/squint at a monolith node as in option 3.

Strong typing is important but picking the correct “add” node among a sea of typed variants is a pain from a UX perspective. TDs just want to add things, the system can then infer the type automatically.

I'd also pick option 2, without hesitation. This strikes the right balance and, for what it's worth, is how Houdini does it which with their VOP graphs (which compile to VEX code).

Well done! Does the particle data need to do roundtrips between the GPU and CPU, or does Blender support end-to-end GPU workflows?