This sounds like just moving the problem. The author makes it seem like writing a Dockerfile is somehow such a burden on development teams when in reality it's a rounding error on the overall development time spent on a project. Ours is about five lines long. Copy the files, define some environment variables and a port, done. Not exactly rocket science.

Part of the problem stems from trying to roll CI into the Dockerfile. Not a thing if you use, Travis-CI, Github Actions, the Gitlab equivalent of that, Google Cloudbuild, AWS Build, etc. Because it's all externalized there. Creating good pipelines with those is a bit of work but also nothing major.

They all follow the same pattern: build pipelines defined in json or yaml that define steps that are effectively dockerized build tools. The only problem your project Dockerfile should solve is copying the output of that pipeline to the container.

I guess a build pack would try to "standardize" CI/CD in the context of a very specific deploy environment and CI environment. Standardizing something that specific has limited value though. What would make sense at this point are dockerized build steps that work in most or all of the above CI systems. They all solve more or less the same problems in a very similar way. But of course where it gets complicated is the deep integration with the stuff outside the build system (cloud specific components, secret management, networking, deployment clusters, etc.).