I don't see why afl-fuzz needs to be turned into a general-purpose Swiss Army Knife framework. It excels quite well at mutation-based techniques that train themselves on resulting outputs. For problems that involve specifically triggering code branches, then a tool that employs symbolic execution methods via constraint solving should be used instead, as the author implies.
The basic idea for AFL is that it's supposed to be reliably better than dumb fuzzers without requiring you to think too much about the problem space, fuzzing settings, grammar definitions, harness design, etc.
Anything that makes it retain these properties while improving results is probably worth pursuing. Conversely, anything that sounds cool but ultimately doesn't meet that criteria is probably a better fit for other tools.
The "without requiring you to think too much about the problem space" is pretty huge and it is where solver-based testing currently falls over (in my experience).
