This is true for early high-level decisions. For every-day coding of smallish components in a large project, it matters much less.
The more code your design decision will affect, the more up-front planning it deserves.
The more code your design decision will affect, the more up-front planning it deserves.
You can't loosely couple around questions like these most of the time, at last not without excessive abstraction.
For "how do I structure this reasonably isolated 0-1kLOC component", I agree, easy to fix later if needed.
And like for example if you want to change web frameworks, that's something you can do incrementally. If you're talking about front-end, just find a way to encapsulate your old code behind a clean interface and start implementing new components in the new framework. If you're talking about back-end, then you can just implement new endpoints in a new language if you want even, and gradually migrate things over when you have to modify them.