At least with on-prem, you can talk to the infrstructure team's management to negotiate adding currently non-supported features.
I was hired at Amazon 8 years ago to implement a couple of features. One of them was difficult because it required communication / buy-in from multiple two pizza teams. By the time I left it was stalled. Three years ago I randomly started at an AWS customer who needed that feature as they had followed the AWS conventional wisdom for setting things up and architected themselves into a corner. I was able to craft some workarounds but they're hacky.
AWS has been promising us this feature "next quarter" for the last 3 years.
If you look around, you can find a number of weird corner-cases where AWS does not make it easy to do the simple thing you want to do, but you can hack around it.
We went looking at GCP and Azure and there are similar issues, though in different parts of the infrastructure.
Not to mention each of them change their interface frequently enough to be annoying. Thankfully, reverse incompatible changes are not at all the norm.
My cloud infrastructure is replete with architectural warts to avoid quirks we didn't know existed until after we deployed. My on-prim components, though managed by a different team, do what we want them to do because the team who built them asked us what we wanted before building it.
AWS weirdness accounts for about 85% of my time. On prim weirdness for 5%. But yes, local-first is obviously a non-starter.