The relationship is not that tenuous. The slogan "SSA is functional programming" means something very specific: dominance relationships in SSA are in one-to-one

The relationship is not that tenuous. The slogan "SSA is functional programming" means something very specific: dominance relationships in SSA are in one-to-one correspondence with nested scope of letrec-based abstract syntax trees (let's call it LRAST). LRASTs support sparse analysis. The connection is quite close: transformations on SSA are in one-to-one correspondence with transformations on LRASTs (e.g. phi elimination is called lambda dropping). You could imagine a SSA intermediate representation that also stores the dominator tree, and where each transformation of IR needs to update the dominator tree so that it stays in sync with the IR. That's what functional language compilers were doing. Although they are formally equivalent, SSA is better than LRAST because some transformations that are easy on SSA are difficult on LRAST. A simple and local transformation on SSA, such as common subexpression elimination, may change dominance relationships and therefore requires restructuring of nested scopes in the LRAST. There have been a lot of papers in the functional programming literature about doing that kind of restructuring for transformations that are trivial on SSA. This is one of the reasons why the optimisations done by SSA based compilers are usually more advanced than those done by LRAST based compilers. The result of this paper was that some functional language compilers switched to SSA. MLton for example.