Updating libs on bare metal has maintainers and distributions, though. And doesn't force you to roll your own security infra within containers.
If you’re using a container based on an OS, you are installing far, far less and having only one process running. That again is a huge savings: no time securing postfix and cron, etc.
Another big advantage is that you’re shifting this work from the deployment time to build time. You do it once and can test it as long as you want before deploying it to production - no more failures because Red Hat’s mirror is unavailable or malfunctioning during your prod update window.
Even if you do a FROM Ubuntu or FROM Debian that's still a huge advantage.
nothing in docker prevents updates, just people in general are poor about doing maintenance, this is a story that is old as computers, and why MS forced updates on everyone because left to their own most people choose to "postpone" them indefinitely for fear of breaking things
It sure would be helpful if the updates didn't actually break things. It's usually not the security fixes that do that—stuff rarely breaks on LTSC, or in Debian point releases—it's all the other changes that get rolled in.
There's just too much churn across the industry. Even if the changes are good, too little thought is given to the cost of change itself.
The problem is not updating your images. Running old libs on bare metal has exactly the same problem.