You don't need a bottleneck to optimize something. On a single-core CPU, you have a certain number of processor cycles available per frame before you create a CPU bottleneck. Optimizing early on (everywhere) really helps when you start adding intensive tasks like A* and real-time line-of-sight calculations.
I disagree. It is far easier to make a correct program fast than a fast program correct. I assure you. I'm not making up the approach at all.
And if you want to get technical, it probably has less to do with the CPU itself and more to do with the amount and type of cache that CPU has, which is again, something the JIT may take into consideration when it emit's it's native code.
This also becomes important once you get into a situation where you have a team of developers. In this situation, code clarity is far more important up front than how fast it is. You can attack that problem later. This is why they invented profilers.
True, but this depends on what you call "optimize". I call "optimize" the process of making your code run faster. If that means avoid seemingly elegant solutions due to better overall JIT results, then that's optimization too.
What is "faster"? Performance is about how the user perceives the responsiveness. Not always about how many cycles you're saving.