At least for us, the promise was not a lower bill, but faster time to market. The requests to on-prem engineers are just _not a thing_, which is much faster for our developers.
For instance, the IT department manager claims to need more headcount and money to fund it, because they believe that having more budget and employees shows how important their function is. Engineering requests a new VM, and the request sits and sits and sits, so long that you start believing that they are overloaded. Engineering complains that it is taking too long to provision machines, and IT (for the 100th time) says they need more headcount to keep up with internal demand. To fix the problem, management grants one or two hires, things get marginally better for a while, until the cycle repeats.
In this scenario, Engineering is trying to get their product completed, and looks bad because the schedule is slipping. If you are the Engineering manager, do you care more about fixing the organization, or sidestepping the issue by swiping a credit card?
Fixing things gets political fast, spending money less so.
Where it is cost-effective, it can still be incredibly strategically limiting.
Not dealing with procurement cycle for h/w purchase is priceless.
Personally, I tend to push for PostgreSQL primarily with near self-service containerized services for the applications and mostly will just leverage the cloud's queues and blob/s3 storage, which are easy enough to replace in a software stack. I'm not big on lock-in.