The problem is it is often very expensive to adapt other components to fit the inflexible platform.
In your example, the customer may have had software that depended on the routers having some functionality that the cloud native routers didn't. Sure if they had designed for that cloud from the beginning it wouldn't be a big deal. But now, that $2M might be less than the cost of changing all their other systems to work around the limitations of the cloud native router. I've seen situations play out like that a few times.
That kind of logic seems to make sense at first, but just confirms my point: trying to change IPv4 to suit you is a fools errand. Change what you do to hit ordinary bog-standard IPv4 instead and miraculously you’ll have fewer impediments.
A random state government department has no "business needs" that require custom IPv4 routing technology that isn't supported by the two biggest public clouds. Any such need is imagined, or an outright error.
In this particular case they were sold a product that serves one purpose: multi-cloud solutions across international boundaries where no single telco can connect all of the data centre locations.
Their handful of locations are all in one city and well-connected by multiple telcos because... they're a state government, not a multi-national corporation. They're blocked by the constitution from expanding inter-state, let alone internationally. That would be a literal act of war.
That didn't stop the vendor's sales team showing slides with titles like: "What if you need to expand into the Chinese market?".
In your example, the customer may have had software that depended on the routers having some functionality that the cloud native routers didn't. Sure if they had designed for that cloud from the beginning it wouldn't be a big deal. But now, that $2M might be less than the cost of changing all their other systems to work around the limitations of the cloud native router. I've seen situations play out like that a few times.