I have worked with database code that was meant to only work with the database it was running on, and database code that was meant to be agnostic to what database you used. I always thought that the costs of the second were underappreciated relative to their benefits. And unless you're actively maintaining running on more than one database (as in, shipping a product where your users have more than one database) you tend to miss all the implicit ways you come to depend on the implementation you're on -- yes, the syntax may be the same across databases, but performance impacts are different, and so you tend to optimize based on the performance of the database you're on.
I suspect the same is true for cloud. Real portability has real costs, and if you aren't incurring all of them up front and validating that you're doing the right things to make it work, then incurring part of them up front is probably just a form of premature optimization. At the end of the day, all else being equal, it's easier to port a smaller codebase to new dependencies than a larger one, and attempting to be platform-agnostic tends to result in more code as you have to write a lot of code that your platform would otherwise provide you.
I suspect the same is true for cloud. Real portability has real costs, and if you aren't incurring all of them up front and validating that you're doing the right things to make it work, then incurring part of them up front is probably just a form of premature optimization. At the end of the day, all else being equal, it's easier to port a smaller codebase to new dependencies than a larger one, and attempting to be platform-agnostic tends to result in more code as you have to write a lot of code that your platform would otherwise provide you.