The complexity has a lot to do with how a contract is structured.

A good lawyer avoids internal cross-references. They're like the GOTO of contracts. On the other hand, lawyers treat "sections" the way programmers treat "methods" – each section is supposed serve a discrete function, and can be leveraged via cross-references to avoid repetition. So you have a tension between DRYing up the contract language and increasing inter-clause dependancies.

Contract assembly technology is pretty useless in my practice, since I'm most often reacting to the other side's agreement form. It's easy to implement basic Madlib-style contract templates, but in the end it's even easier to just edit a Word or text file. After all, as soon as the other side gets your draft, they make changes, and all your precious metadata goes pretty much out the window.

I'm more interested in tools that help me make smart decisions based on best practices, and what options/risks I ought to consider based on a completely arbitrary contract input.

Or it might be as easy as writing a compiler. These things are hard to prejudge.

Compiler writing is easy? No. (I've built compilers for large subsets of C and Java, as well as my own languages)

Lord help you if you try to write a perfectly conforming compiler for C++ (has it ever been done?), and the U.S. legal system is at least an order of magnitude more complex than that.

To make that task even more complicated, people don't agree on what many of the rules are. Your "law compiler" would have to take in input and have output that's maybe this, or more likely this, but it could also be this...

Compiler writing isn't the easiest thing in the world by any stretch, but it's something that we manage to achieve all the time, unlike the mythical "program to do my programming" we are so quick to imagine.