Often enough, implementing the optimal solution is not really more time-consuming than the brute force solution. Often it's not about micro-optimizations, but a difference between O(n^3) and O(n*logn).

I guess I think of programming in a big company as a team exercise. And thus the hiring pipeline can take advantage of specialization and good-enough economics, as well as teaching people more on-the-job. It's a large burden if you demand everyone on the team know the same first principles (of course there may be disagreement on what those are). Even if personally I want to know as much as I can and get along with others who do too, I'm not really going to hold it against a team member if they produce a poor-complexity algorithm that in review I (or someone else, I think it is good to have at least one person on the team who has algorithm knowledge) notice and can suggest an alternative that's easy to use instead. If they do it again (for the exact same thing) I might raise an eyebrow and remind them of the repeat mistake. If they do it a third time I might write them off as incapable of learning new things. But this pattern applies to other aspects of software too. e.g. Getting people to write testable code can itself be a hassle if they haven't been exposed to that before. Or something as dead simple as getting people to use the rest of the team's coding style guidelines, I've seen interns who still had problems with that near the end of the summer internship, I wouldn't be very happy if it was a senior colleague...

The problem is when the goal is to get something out of the door as soon as possible. In such cases developers tend to settle for the first thing that comes to their mind, which is rarely an elegant solution.

These require experience and time spent carefully designing the system. A profiler shows you what is slow in your current implementation, not how to convert it to a more elegant one.