It is not inherently necessary for Pipeline Groovy libraries to be checked out into the workspace/xxx@libs/ subdirectory at the job level, or updated after the initial checkout, and then copied into the build. It suffices to check out the SCM directly into the build directory.

• Reduces disk usage somewhat. While there are typically many more build directories, each with their own copy of the library, than the one shared checkout, the shared checkout will include SCM metadata (like the .git/ directory) as well as any files not needed at runtime (documentation, tests, unrelated projects).
• May avoid contention in heavily concurrent jobs, since no global exclusive lock is needed during SCM operations.
• Is generally simpler, bypassing some security and other consistency issues associated with maintaining a checkout shared between builds.

The downside is of course that a fresh checkout tends to be slower than an update operation. In the case of Git, the overhead can be minimized using shallow clones and some related options, especially since there is no requirement that the checkout be configured to support subsequent pulls.