Although this has been discussed in JENKINS-48692 and in https://github.com/jenkinsci/job-dsl-plugin/pull/1098, I would like the Job DSL plugin's maintainers to reconsider the decision to not support newer versions of PostBuildScript in light of the fact that the experience with configuring a post-build build step is different from a build step defined in a steps block. For example, one would expect something like this to work:

postBuildScript {
  buildSteps {
    postBuildStep {
      buildSteps {
        criticalBlock {
          shell 'pwd'
        }
      }
    }
  }
} 

When in reality,  criticalBlock and everything inside of it would need to be configured differently, owing to the fact that it isn't executing with respect to a StepContext, and criticalBlock itself is nontrivial in its implementation. (Similarly, configuring a shell step is different with respect to a StepContext compared to the dynamic DSL context, given that the implementation of shell shortcuts the command part.)

Additionally, while it is true that PostBuildScript itself handles configuration of its older configuration generated from the existing postBuildScripts step (including migration to the MatrixPostBuildScript class, new to newer versions, where applicable), and that dynamic DSL does cover most remaining features (notwithstanding the build step inconsistency described above, and that dynamic DSL may not be available in certain use cases), it is to be noted that there is prior art of a step in Job DSL supporting multiple versions of a plugin (via the isMinimumPluginVersionInstalled call). Additionally, competing job configuration solutions (eg. Jenkins Job Builder) handle the configuration of PostBuildScript in a suitably version-agnostic manner.