If you're making a complicated webapp, use your favorite framework to make it functional, and then if it's functional and not already fast enough, look at the slowest parts and replace them with faster alternatives. It's not going to result in the most elegant solution, but in most cases it will be good enough. Better to have something that works than to spend an extra year reinventing the wheel.
The problem/trap in that case is, a lot of throwaway code ends up not being thrown away in the end, up to and including the prototype becoming the product (even if it was never meant to be).
There's also the old saying about how a good programmer is lazy. There's two ways to interpret that. Seems we've shifted to the bad kind of lazy (i.e. easy/minimal upfront work)
It's sort of like "premature optimisation is the root of all evil". That shouldn't imply you should use completely the wrong language and data type.
You need to think about where you are going. Just that you shouldn't be focussing on micro problems when you haven't finished the big picture as it were.
To my mind we should be talking about problems as fractals. Get the broad shape right, and then start zooming into the details. That doesn't mean you should start off with the wrong shape.