Cache coherency matters, and making sure a large data structure fits in memory is important too. If you can't fit it, at least make it nicely match up to page boundaries. If you don't understandt he implementation of your choice array / set / map / tuple data structure that you are throwing around all over the place, you could be missing plenty of performance just from TLB misses or some other hardware voodoo.
Yes, all of those make a difference. Sometimes a big one.
But in general, it is best to just try to be reasonably sane and not worry about it until you have a proven problem. A surprising fraction of the time, a "reasonably sane" approach is not that far off from optimal. And setting the bar there helps development speed.
Which, of course, is what you care about when you choose to use a scripting language. If you care more about computer time than developer time, then using a more efficient language makes sense.
This matters if you are Google, serving gigabytes of data per user for free. This matters less for sites whose compute budget is 10% of their human budget, where trying to cut from 2x to 1x on compute isn't worth the human cost.
Poor logic on their part if so. Slowing your programmers down 2% to cut 10% off your hardware costs is usually a bad idea, and that's still true as your budgets for both grow, as long as the ratio stays the same.
(I don't think Google are stupid, I think their ratio probably has shifted to the point where their hardware budget is comparable to their salary budget. Which makes them a very unusual case)
