Not to mention Spanner was first to pull off this combo of performance, consistency, and availability. The others claiming similar things are one pulled off market and one just beginning (unproven). It's not just cost: they're either going to have to clone Spanner with clean-slate project, exhaustively analyze/test CochroachDB to see if it's mission-ready, or invent their own magic that does what most DB vendors couldnt pull off. They'd be spending a lot of money on something that would likely crash and burn when all the odd errors hit it.
Most enterprises that have to maintain global consistency are better off with Spanner. I doubt there's many, though, that really need that vs splitting stuff into locales that are consistent in a smaller, geographical area that allows regular, DB clusters.
better off using non-free software for mission-critical services
it may be true that spanner is currently better than any free software option, but you are much better off contributing to a free software project that solves this problem than paying google to keep developing their non-free alternative.
FOSS and commercial sector tried and failed to do stuff like that for over a decade. I agree developing it is better in the long term but most don't have the skill to solve that problem. Better to buy a proven solution, make sure you can exit it (not sure what Spanner is like here), and switch if a FOSS solution emerges.
If they don't need sql they could try CosmosDb from MS. It's not proven outside MS yet either but I do have more faith in their testing than in most open source solutions.
"Azure Cosmos DB accounts that are configured to use strong consistency cannot associate more than one Azure region with their Azure Cosmos DB account. "
...it lacks Spanner's ability to work across geographical regions. It's otherwise a full-featured, distributed, DB service. Lots of tradeoffs allowed.
Most enterprises that have to maintain global consistency are better off with Spanner. I doubt there's many, though, that really need that vs splitting stuff into locales that are consistent in a smaller, geographical area that allows regular, DB clusters.