My experience is that shipping stuff that doesn't get used by any actual end users is more often caused by thinking ahead too much than by thinking ahead too little.

I've actually seen it both ways: whole features (or even products) that were too early. But on the implementation level, I've seen someone pick the wrong thing (library, database, whatever) "because it was simple", only to have it be thrown out before getting any real usage.

"Pick the wrong thing and then retract, losing some work" is as close to optimal as you can get. Iterate.

The much worse outcome is "pick a thing, fiercely defend it whether it helps the ship to float or to sink".

I agree that outcome is worse. However, both extremes are bad. The optimal approach would be to do a little bit more work upfront, pick a "better" thing (where "better" is at least more than the next sprint or 3!), and use that.

Even then I'm not sure. Sometimes the quickest way to discover the problems with something is to try it on the real product.