We do similar thing but with workflow plugins.

You only need recognition-memory to use Web and GUI interfaces, whereas you need recall-memory to use command line interfaces and scripts, which is far more difficult. That's why clicking in a Web GUI or graphical XML-generator replaced scripting. You need a lot of previous information in your memory for recall to write stuff like the following example taken from your linked page:

  def project = 'quidryan/aws-sdk-test'
  def branchApi = new URL("https://api.github.com/repos/${project}/branches")
  def branches = new groovy.json.JsonSlurper().parse(branchApi.newReader())
  branches.each {
    def branchName = it.name
    job {
        name "${project}-${branchName}".replaceAll('/','-')
        scm {
            git("git://github.com/${project}.git", branchName)
        }
        steps {
            maven("test -Dproject.name=${project}/${branchName}")
        }
    }
  }

The vocabulary and grammar in that script is quite complicated and people would rather be presented with the options for clicking on a web page. But perhaps you're promoting a particular software product?

I also used JobDSL, and thought it worked pretty well. I don't think my teammates agreed, they seemed to just want to change things in the UI and this was just something getting in the way of their work. Some were willing to learn it, others weren't interested.

I think the new Jenkinsfile approach looks very promising: http://jenkins-ci.org/content/pipeline-code-multibranch-work...

Jenkins Job Builder is, IME, the only way to keep complex Jenkins configs sane. Did you know that Jenkins is constantly rewriting its own XML config? We've had Jenkins itself corrupt its own config (with some combination of active plugins).

Keeping your configs in YAML in source control is such a win. Not a fan of Jenkins, BTW.

We use this to generate builds from our (many, many) feature branches, its amazingly useful, bravo!