* configure jobs as code (https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin)
* system configuration as code (https://issues.jenkins-ci.org/browse/JENKINS-31094) and its current prototype (https://github.com/jenkinsci/system-config-dsl-plugin)
* bypassing setup wizard (https://issues.jenkins-ci.org/browse/JENKINS-34035)
There are also puppet modules, Chef cookbooks, and etc that a lot of people use. Some of those are maintained by people who are also in the Jenkins community, so I don't consider them "3rd party hacks" if you are referring to those.
So, great, there is a plugin to deal with configuration. How do I bootstrap my infrastructure? If it's a plugin, it sounds like I need to install that in an already running Jenkins setup, no? Currently, both this and the bypassing setup wizard seem like hacks to me.
Configuration of a critical piece of your infrastructure should never be a hack.
Regarding plugins, you can just plop them in the plugins folder an start Jenkins.
I still think core functionality shouldn't be put into plugins in any software system. You should have sane functionality and defaults right out of the gate. Plugins or modifications are for extending the base use case. Configuring your software to me is a base use case.
What they did instead was to move most of the core functionality in plugins maintained by the core contributors, so they're plugins all but in name. I.e. they can be installed separately, uninstalled, etc., but about 100 plugins are supposed to be used together and you see them frequently in examples, docs, etc.
That "about 100 plugins are supposed to be used together" is indicative of bad design to me.
They really should be taking a look at modern systems like Concourse CI to see what they can do to improve.