Putting the application in a container doesn't make it easier to make safe, controlled changes to the internal workings of the application. It doesn't help any developers understand the theory (if any) underlying the application code, that might help them understand how to code with the grain when making changes.
Stuffing it into a container to deploy it is orthogonal. It doesn't solve many problems
I have worked professionally in a company that is a giant, sprawling software slum at best. Containers are huge there because they are perceived as fixing this issue even if they just make it worse in practice.
I see containers, at least when used this way, as a consolidation loan for technical debt. They let you consolidate your existing debt load embodied in all your messy uninstallable ball of crap software and then max out your credit again.
One of the issues here is the lost art of writing installable and well-organized software. It's quite normal these days to have services and apps that consist of multiple often redundant services and sub-applications wired haphazardly together with crap strewn all over systems.
It may sound contrarian, but I was very, very recently looking at a project that uses three or four different base containers because the people involved can't agree to use the same flavor of linux.
It's more like they are doing the technical equivalent of credit card churning but never closing out the accounts. I have never seen anything like this, and I have, on and off in my career, worked in contexts best described as "software superfund decon expert."
Stuffing it into a container to deploy it is orthogonal. It doesn't solve many problems