Still peanuts compared to public cloud costs.
I work at a holding company with several saas applications that have been acquired over the last decade or so. Some are traditional design hosted in a colo (three tier web/app/db), some are shiny k8s/RDS implementations in the public cloud.
The costs for the systems in Public Cloud are at a minimum 5x what the same systems cost in the colo. The colo costs are one of the smallest spends in the colo equation.
Yes, we still need experts in storage, networking, computing, OS, etc. But these same individuals are put to work on the cloud stuff as well. No big surprise that the devs that put things in AWS don't think much about backups, DR, what's really required for HA, etc. Even if everything moved to the cloud, the same people would have jobs doing work in the cloud instead. Maybe a few would leave because it's not their skillset and they would do better elsewhere, and then you need to find new people that are cloud familiar to work on things, and they are not cheap.
Last and most importantly from a cloud vs. colo cost perspective, the cloud costs generally rise in a linear fashion. Add a new customer that needs more compute and storage, it's going to rise in a linear fashion. There is a greater economy of scale to be had in the colo. There is generally more slack in the compute and storage systems there, so it could cost nothing. Even adding a few servers and another shelf isn't going to break the bank when cloud is 5x more overall.
We are looking at more ways to move things out of cloud and back into colo. It just costs far less, and we already have the people.
As to the whole notion that AWS/Azure have AZs that recreating would cost a fortune do in a colo, but he colo model vs. the public cloud model are not the same. The colo is designed so that nothing is on hardware that isn't redundant or a cluster that cannot survive multiple host failures. There should not be site downtime at a colo. They all generally have blended internet connections as well.
AWS will tell you straight up that an app should be designed for multi-az fail over. #1 This sounds easier than it is, #2 - if a whole AZ goes down and all these apps try to start up in another AZ, it will be a small disaster. Storage in the other AZs will be under tremendous strain, and compute may be unavailable. This has already happened several times in the past decade with AWS, and everyone seems to forget about it. Heaven forefend one of these AZs is lost for several weeks, or forever.
In a colo environment, we have a DR site hundreds of miles away from production sites. Yes, it would take a bit to get it up and running, but it's there if we need it. The compute and storage is all dedicated to our company. We take our old production hardware and set it up as DR. It costs nothing, and since it isn't on, we don't have a bill from the colo company for electricity or power.