While I know little about JS, I am aware of one complication it brings to the docker world, that of environment variable values being placed into the code as the application is built. The result is a lot more content than must be connected to the docker container, rather than held in the container. I would guess that the strapi team are trying to avoid this complication.
The thing is that this is not hard to deal with once you have the underlying toolset - you just have the CI system create dedicated containers for each target environment. I already do this for another JS based container, with the end result being a dedicated container for each of my DEV, TEST, DEMO, STAGING, and PRODUCTION targets.
Once I have even a basic understanding of what I am doing I should be able to take the output from your tool and the examples in the docs and get a CI driven build running, but others in my position may instead just switch to their next CMS choice.
At the moment I’m expecting to end up with very few volumes connected to the container as .env will be handled by a secret manager and /src, package.json and yarn.lock will be within the container so that they do not change. There is little point in having a CI process if someone can add modules or do updates at different stages of the pipeline.