The recent 12 x Google Maps API price hike is another such "exception that proves the rule" apparently.
Over a sufficiently long time horizon, the chance is much greater than 0.01% and the longer you go without doing the work, the more it costs to do the work.
Sure, it's more a problem that bites you when you've become a big enterprise, but it bites hard, and some of us work in big enterprises on systems that could reasonably be operational for generations going forward (and perhaps have been going backwards.)
And that's the right choice in some cases. But the added up-front effort can be a lot less than the added reengineering effort, and growing into a big enterprise doesn't mean you are immune to disruption by more agile startups.
And, of course, those who are already in big enterprises have different concerns (while premature adoption of the mitigations at issue can be engineering resume padding in startups, deferring it with the hope that it won't be a crisis until it's someone else's problem in exchange for short-term metrics can just as easily be management resume padding in enterprises.)
I don't think it's 100x or even 20x less work.
There's certainly a continuum here. The most minimal risk mitigation strategy is simply to use your own domain (as opposed to the vendor's domain), and that requires nearly zero effort. Unfortunately the team in that article made that mistake, and they're pretty honest about admitting it.
Assuming you don't make rookie mistakes at the beginning, you always can move to another platform - it's just a question of how much work it will take. Is it better to put that work in up front for the 0.01% chance you'll need it? I think not.