The crucial choice is not (just) the one made in a pivot: choosing any DB (or any similarly foundational stratum of your system) is always a crucial decision. Ultimately, you have two choices: put off making an informed, optimal choice, or make an informed, optimal choice now - or if not now, then as soon as you have enough data/experience to make the optimal choice for your needs.
I think you might be attributing the bulk of potential cost to the act of migrating away from an initial choice. But the cost of migrating away from something is proportional to the extent to which it is intertwined/coupled with your system, which in turn is largely a function of the scale at which you are operating. The problem, at least as I have seen it, is that organizations often pick something with minimal (if any) thought put into that initial choice, wait until scale reaches a point that switching away is matter of life and death, and then have to desperately fight against inertia. I think that's what the parent of your post is getting at.
Yes, when decision can be delayed, that is powerful. But we are discussing decisions that have already been made which need to be unmade or made again. Where it breaks is when the tech debt is growing faster than our expertise. The usual stall is not to allow time to apply resources to the problem but to continue to not apply resources to the problem. So our knowledge base is growing at a negligible rate. Particularly if you’re a first mover. Nobody will solve your problems better than you have until it’s far too late to migrate to their solutions.
Counter-point - the longer you delay a crucial decision the more information you have to make it a correct one, so you might avoid migrating DB engine twice a year