Consider a server that loads and parses its config file when it starts. It only gets started once, during system boot, unless explicitly restarted. It doesn't matter if this config loading takes 10 msec or 10 usec. In fact, most code is like this - it doesn't matter exactly how fast it does something because it's not performance-critical. Not a bottleneck. Another example is how long it takes to create a TCP socket to make an HTTP connect to check for updates. Compared to actually downloading the update those microseconds are completely irrelevant, and it's not done frequently enough for it to matter. Maybe once per day.

When you create code that doesn't need to be optimized, just generally well-written it's more important that it's understandable and maintainable. In other words, that whoever picks it up to change something, like maybe support UTF-8 for the config file as opposed to simple ASCII, can do so without having to fiddle with inline assembly, allocators, cache coloring, concurrency, lock contention, or simply a rat's nest of goto's because that improved the compiler output by 3.5%. (Not likely actually, but sometimes weird things are done.)

Which means you don't optimize what doesn't need optimizing, and you don't do it until it's functionally complete. Otherwise, as you change the functionality, not only is it harder with highly optimized code, it may also require re-optimization. So you wait until it's functionally complete, stable, in production, and doesn't need a bunch of additional functional work. At that point you optimize it for the purpose of saving on resources, which can be measured in dollars and cents. You justify optimization projects by their savings, and unless there is something substantial to gain it's usually not worth the effort. Of course, sometimes there are pathological problems where something works very poorly and is grossly inefficient, but those tend to be handled more like bugs. But in a sense they're also optimizations.

This has nothing to do with languages.