It’s a fun crack at the problem. I’ll say (very annoyingly) that I have a hunch that the formalization is fundamentally wrong somehow that I can’t quite put my finger on, even though branch factor does seem like a really great candidate for the relevant measure.
One of the first principles I learned in programming was coupling and cohesion. This type of graph-based measurement of program complexity already existed some 60 years ago.
I think your hunch is on point, I think because the author conflates running time of a busy beaver with benchmarks of programmatic coupling and cohesion.
Busy beaver algorithms are single-purpose programs. An eCommerce website is layers upon layers of interrelated modules and functions.
I get where they're going, reducing a problem space down to its simplest representation is ideal. I just don't on first pass understand how busy beaver accomplishes this.
I'd guess it's wrong too. It looks as if it's trying to cluster states, but the part that says "repeat transformations until no changes are possible" suggests it might eliminate too much for the sake of a simple formulation.
In a 2-symbol TM, there are at most two outgoing edges in a state. If you remove the self-reference, you're left with just one. That seems to remove too much of the hidden complexity.
I suppose the thinking behind it is "a loop is not spaghetti code", but a loop in higher level language rarely translates to a single state moving to itself.
OTOH, it's possible to write spaghetti-code in a system that only has while loops and if-then-else by simply having very complex conditions, and modifying the variables on which they depend at seemingly unrelated points in the code. After all, both are TM complete.
