Which parts of the system are you considering when you make that evaluation? Introducing SSA nodes is certainly simpler if you consider dxil.c in isolation, or even the dxil -> spirv path in isolation. That's (trivially) not true when you consider e.g. d3d_asm.c or spirv.c in isolation. Similarly, SSA nodes are extra work for someone adding e.g. a MSL or GLSL backend. What about transformation passes in ir.c? Are those potentially going to need to handle VKD3DSPR_SSA? We don't run any of the existing ones on dxil sources, but that doesn't make the consideration just go away.
As I said, I agree with Henri that it would have been sensible to first use temporaries, but as a side consideration if we eventually introduce SSA I don't expect that necessarily every consumer of VSIR is expected to handle it. We could internally have a few different dialects, for example one that allows SSA and one that doesn't. And maybe a pass that lowers SSA to temporaries, so that a SSA-less consumer can be chained with a SSA-ful producer. Maybe even a pass that raises temporaries to SSA (i.e., a copy propagation pass), if that turns out to be useful.