I've also been doing that for about 25 years, with a similar list, and full automation since ~2001 or so. I haven't found that approach to scale very well because it requires a much higher level of sysadmin skill & application-level knowledge, maintaining a somewhat extensive list of backports or custom builds, and the ability to customize each application to work with a filesystem layout which avoids the conflicts which inevitably arise. Automation is important to making that work at all but it still means that any time things change hands there's a non-trivial amount of code to review before you are confident about making changes and it tends to require elevated privileges or greater levels of coordination between the developers and operators.

The reason why containers are popular is that you get a simple way to manage all of that and it's completely standard on every project. App A doesn't need to be modified to coexist with App B because they're running in an isolated environment, the sysadmin doesn't need to learn how the container was built just to manage services or deploy new instances, builds are much faster because of the layering model, you can deploy a single tested image with no chance of differences creeping into your automated deployments in testing & production, etc. All of that is something which you can achieve with other tools but there's a huge win to not having to reinvent each wheel when you encounter it and being able to reuse other people's work easily.

Note also that I said “containers” instead of Docker — some people might prefer, say, podman / buildah but the key concepts of having a clear support boundary with an isolated-by-default filesystem model are really more important than the implementation.