Any API/CLI/whatever for any package can ensure the consistency/validity of the generated configuration as changes are made, migrate configs across software updates, etc. All of that gets thrown away when you generate the configuration files directly from external automation tools, so that should be a last resort generally and GlusterFS is no exception. I had to do that for HekaFS but, even as someone in a position to influence GlusterFS changes that might break HekaFS-generated configurations, I still consider it an unfortunate necessity.
The configuration-file format itself is very simple. I wrote a Python parser/generator for it in an hour or so. Generating a correct set of configuration files, in terms of satisfying dependencies or layering constraints between translators, or setting all the necessary options, is a bit harder. We also support live configuration changes without restarting daemons, and generating the RPC messages involved to notify them of config changes is all but impossible (not to mention insecure) outside of the current management infrastructure, so a chef-based approach based on rewriting config files would be demonstrably inferior to what's there already.
If there are things that need to be done to make chef integration with the CLI easier, by all means let me know via Bugzilla, email, IRC, whatever. I'll be glad to help with that, but not with an approach that has been tried before and always caused massive breakage.