A lot of time it's the question of "should we be writing this piece of code in the first place?" rather than "how much should we optimize this code?" If we decide we need this code, we try to deliver it in high quality. I think even for internal applications, these are meant to automate paper-pushing jobs away, and they will be used more as the company grows. Using a polished internal application is actually a nice morale boost. It shows that someone cares, and it encourages other employees to put the same efficiency and attention to their work.
I have been developing software for the enterprise for nearly 40 years (back before we called it "the enterprise") and I can count on one hand the number of times we have been asked, required, or had the time to do ANY Big-O analysis of algorithms. In the early days we wrote a solution to the problem and then examined how it performed. For some of these solutions some pre-coding analysis would have been helpful but the demands of the data requirements in the old days were such that the only bottleneck was external access (database, network, storage, user).
Nowadays with the thousands, or even millions, of users hitting a resource concurrently, I think that pre-coding analysis of subsystems that can be identified as bottlenecks should be performed early and often.
The biggest problem I have seen over the past 20 years comes from large teams of "junior" programmers who learned how to do one thing in school (call it 'A') and have a very difficult time adapting to different problems (call them 'B') because these new issues lie outside their field of expertise, which is, admittedly, limited. I blame the paper mill universities of the world for turning out "software engineers" who can't get from A to B (and yes, DeVry is one of them). Basic problem-solving skills are a must for doing this job and analysis of future development is essential.
Code reuse is also not being done to the level that would help speed up both the development process and the performance characteristics. The key question from the above quoted post being "should we be writing this piece of code in the first place?" and not "should we optimize this piece of code to get Big-O levels of efficiency?"