In programming, as in life, we balance requirements, optimize for some things, and compromise on others.

I will assume that when you say "effeciency" you mean "clock cycles, and ram required, to perform a process".

So let's start by saying that probably all code could be improved to go faster and/or use less ram. Given enough time most things can be "improved".

But there's a price to be paid. Most code starts as "easy to read", but least performant. Performance is improved, usually at the cost of readability, until its "fast enough".

Readability impacts future maintainability, code thats hard to read may contain bugs (especially for edge cases) and may introduce security flaws.

I've worked on libraries, making them highly performant, but the code inevitably becomes more opaque. For a library the trade off is worth it.

For that sales report, that runs once a month, and takes 10 minutes, but could likely easily be optimised to run in 2 minutes, the trade off is less obvious. Keeping the report easy-to-maintain is a valuable long-term benefit.

Computers are not the only clock-cycles to measure. Developers also have limited time, and time spent doing one thing is time not spent elsewhere. Sure I can spend my time making something happen in 1 tenth of a second, instead of 2,but if the difference is not human perceptible, what's the point?

Incidentally this question is usually paired with "is software more bloated", and it is, primarily because there are more users who want to do more things. Hard drive space is cheap. Making programs "small" is very expensive.

So yeah, compromises. In time, space and money.