We use declarative pipelines, but do have custom steps which use a lot of functions from the currentJob variable.  We like this, as it feels like the right thing to do rather than calling Java functions directly.  Lots of credentials, withEnv, logging of messages, dynamic spawning of additional stages, etc.  

Attached is a screenshot demonstrating how the current default verbosity level of the "pipeline steps" view could be considered "prohibitive" as the complexity of a job increases.

Blue ocean is an alternative view, but my organization does not want to be required to use blue ocean plugin to view their jobs.  They like the Pipeline Steps view under normal circumstances. 

I suggest adding a mechanism to improve this view at scale.  There are probably a lot of ways to approach that.  I will discuss two below.

One way would be, for each call to currentJob.function(), it would be nice if there was an optional parameter for rendering it: "hidden" or something.  This seems completely infeasible however because it involves overloading each function, and also because conflating these kinds of dynamic functions with their graphical representation seems bad. 

Another way (this one focused on feasibility) might be to add a new function: 

currentJob.hide(Closure c)

Wrapping any function call inside this would tell ther workflow-job-plugin (and potentially any view-oriented plugin) to hide it.  Then, on the page that renders, there could be a button "show hidden steps" which would expand these.  There's a question of transitivity of the "hiding".  In the screenshot, I don't want all the "Set environment variables" to show, but I do want "Execute in parallel", etc.  So, this would probably lead to needing the following functions to implement this "robustly":

currentJob.hide(Closure c) (not transitive)
currentJob.hideAll(Closure c) (transitive)
currentJob.show(Closure c) (overrides hideAll) 

I would be open to any other suggested ideas, assuming they don't say something like   "just use blue ocean".

Of note, this suggestion would also solve one of the problems discussed in this issue: 

https://issues.jenkins-ci.org/browse/JENKINS-44085

Wherein the wait() block renders terribly as seen in the second screenshot attached (jenkins-parallel-waits.jpg)

 Edit: 

If it were technically possible/feasible for Jenkins to have conditional behavior based on Java annotations in Jenkins Shared library code, then that would be the "most desirable" and ergonomic way to tune a cross-cutting-concern behavior like rendering behavior.  

I notice that @Grab and @NonCPS are annotations that are supported in Jenkins Shared Library code... so this seems feasible.

IF it's possible, then the implementation would probably largely occur here:

https://github.com/jenkinsci/workflow-support-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/support/visualization/table/FlowGraphTable.java

Functions could be annotated with @FlowGraphTableHide / @FlowGraphTableHideAll  / @FlowGraphTableShow (or something like this), and the FlowGraphTable code would then be updated to comprehend these.