An implementation of
JENKINS-29922 would simplify the syntax without any action on your part.
You would benefit from a custom step only if the semantics were indeed simpler or different for Workflow. For example, some of the more exotic logic elements proposed for Copy Artifact 2.0 (and even some of the logic in 1.x) could be written directly in the user’s Groovy code, using if-statements and loops and so on.
Yes the result would be somewhat more verbose, but on the other hand it is clear without reading any external documentation what the script is really doing, and you can make minor customizations (“pick the last stable build, or an unstable build if there has been no stable build in the past week”) without having to wait for your weird use case to be supported in the Jenkins plugin code. Common use cases can be packaged as script libraries or just written up as examples in plugin documentation.
Enabling this kind of usage means providing lower-level steps and/or Groovy objects that can offer safe (@Whitelisted) access to critical information about Jenkins builds. There is already a RunWrapper in Workflow, though currently available only as currentBuild or the return value of the build step; could be expanded to let you get, say, the lastBuild of a job which you have Item.READ access to.