I didn't know that, thank you for kindly enlightening me! So from the blogpost, the "compiler debug dumps" are the optimized graph data struct, and instead of converting to assembly or byte code, they want to "decompile" or convert back to ruby. Do you think they're doing this to better understand and improve the compiler? Or to write code that is more easily compiled?

I suspect this may have originally developed as a debugging aid, your “to better understand and improve the compiler”, but also to better understand how Ruby programs execute. With non-trivial data structures and algorithms (such as sea-of-nodes here), being able to visually introspect statically, and/or visualise its operation dynamically, can often provide informative insights.

Instead of, or perhaps as well as, converting to assembly or byte code, here the author is producing a visualisation of the internal graph structure contained within the compiler.

The graph isn’t necessarily a one-to-one match with the AST derived from the source, due to graph transformations that take place during the optimising phase of the compiler/runtime. This makes it even more important/interesting to see what is going on under the hood.

Usually, in high-level programming languages one rarely has concerns regarding how easily the compiler might deal with the code - one just codes, and uses language features appropriately, as needed. With the only caveat here being the extreme performance crew, e.g. games programmers might use a restricted subset of C++, and also might disassemble compiler output, and use that information to help try and optimise their source somewhat.