TLDR; This would be an exciting capability. I personally know many people in OSS and enterprise who would gladly give up "resumption" as a feature if it meant that shared libraries could be written in "stock groovy" (or as nearly stock as possible).
I have worked on several large jenkins shared library projects at several different companies, and the cost of CPS has always been exceptionally high in those cases. Although interestingly, not in the ways you have listed. Even with very large shared libraries, the compilation time and execution time of the groovy code has NEVER been a source of discussion. They've never been a significant contributor to overall job times. In contrast, the cost I'm thinking about has come up in just about every enterprise and oss community discussion about jenkins shared libraries which I've been part of, so I'll summarize it here.
I'll first refer to a metaphor popularized in an old blog post which gained a lot of notoriety and became a meme in the wider programming language community. This post describes the fundamental situation pretty poetically, but with respect to async/sync functions.
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
In summary, CPS "forks" the functions in a program into two colors, in almost exactly the same way the addition of async/await does, CPS makes groovy functions red. Any functions which can't be CPS translated and are marked @NonCPS are blue, and the crossing between them is either impossible, or fraught with peril and misfortune when it is possible. Local testing, debugging, and predicting the outcome of a change across many pipelines all become vastly more complicated because of the existence of CPS.
I know this isn't news, but as a user, this complexity is the most significant cost of CPS by a wide margin.
I love the study CPS from a programming language standpoint, and, the use CPS to provide the capability of resumption for Jenkins Pipelines is novel and brilliant thing. I'm sure there were some teams and companies who needed such a capability, and benefitted from it greatly. I've certainly been pleasantly surprised a few times by having it work during unexpected or unfortunate Jenkins master restarts myself.
Nonetheless, it's worth pointing out that across multiple devops teams I've worked with as a consultant, and the ones I've worked on as a team member, successful resumption of pipelines during a restart of master was never expected, trusted, or planned around. Resumption can simply never be guaranteed. Restarting Jenkins was a major event, and required a maintenance window where jobs. If Jobs were scheduled or still in flight during such windows, it was widely understood that they would almost certainly fail (and they almost always did for one reason or another). There are just too many conditions outside of Jenkins which can undermine the resumption. Plugin upgrades, jobs which call Jenkins internal API's and REST APIs, the implicit checkouts that take place on master... etc.
So, from my perspective (which is still very limited compared to many others who might read this), I think many organizations would say that they would rather not pay the total cost of ownership for the ability to resume. My guess is that it wasn't feasible to implement it as opt-in from the beginning, but now that there might be possibility to opt-out in the future, it's very exciting.
TLDR; This would be an exciting capability. I personally know many people in OSS and enterprise who would gladly give up "resumption" as a feature if it meant that shared libraries could be written in "stock groovy" (or as nearly stock as possible).
I have worked on several large jenkins shared library projects at several different companies, and the cost of CPS has always been exceptionally high in those cases. Although interestingly, not in the ways you have listed. Even with very large shared libraries, the compilation time and execution time of the groovy code has NEVER been a source of discussion. They've never been a significant contributor to overall job times. In contrast, the cost I'm thinking about has come up in just about every enterprise and oss community discussion about jenkins shared libraries which I've been part of, so I'll summarize it here.
I'll first refer to a metaphor popularized in an old blog post which gained a lot of notoriety and became a meme in the wider programming language community. This post describes the fundamental situation pretty poetically, but with respect to async/sync functions.
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
In summary, CPS "forks" the functions in a program into two colors, in almost exactly the same way the addition of async/await does, CPS makes groovy functions red. Any functions which can't be CPS translated and are marked @NonCPS are blue, and the crossing between them is either impossible, or fraught with peril and misfortune when it is possible. Local testing, debugging, and predicting the outcome of a change across many pipelines all become vastly more complicated because of the existence of CPS.
I know this isn't news, but as a user, this complexity is the most significant cost of CPS by a wide margin.
I love the study CPS from a programming language standpoint, and, the use CPS to provide the capability of resumption for Jenkins Pipelines is novel and brilliant thing. I'm sure there were some teams and companies who needed such a capability, and benefitted from it greatly. I've certainly been pleasantly surprised a few times by having it work during unexpected or unfortunate Jenkins master restarts myself.
Nonetheless, it's worth pointing out that across multiple devops teams I've worked with as a consultant, and the ones I've worked on as a team member, successful resumption of pipelines during a restart of master was never expected, trusted, or planned around. Resumption can simply never be guaranteed. Restarting Jenkins was a major event, and required a maintenance window where jobs. If Jobs were scheduled or still in flight during such windows, it was widely understood that they would almost certainly fail (and they almost always did for one reason or another). There are just too many conditions outside of Jenkins which can undermine the resumption. Plugin upgrades, jobs which call Jenkins internal API's and REST APIs, the implicit checkouts that take place on master... etc.
So, from my perspective (which is still very limited compared to many others who might read this), I think many organizations would say that they would rather not pay the total cost of ownership for the ability to resume. My guess is that it wasn't feasible to implement it as opt-in from the beginning, but now that there might be possibility to opt-out in the future, it's very exciting.