> This is specious reasoning, as "optimized" implementations typically resort to performance hacks that make code completely unreadable.

That really depends on context, and you're generalizing based on assumptions that don't hold true:

Replacing bloated ORM code with hand-written SQL can be significantly more readable if it boils down to a simple query that returns rows that neatly map to objects. It could also boil down to a very complicated, hard to follow query that requires gymnastics to populate an object graph.

The same can be said for optimizing CPU usage. It might be a case of removing unneeded complexity, or it could be a case of microoptimizations that require unrolling loops and copy & paste code.

---

I should point out that I've lived the ORM issue: I removed an ORM from a product and it became industry-leading for performance, and the code was so clean that newcomers would compliment me on how easy it was to understand data access. In contrast, the current product that I work on is a clear example of when an ORM is justified.

I've also lived the CPU usage issue: I had to refactor code that was putting numeric timestamps into strings, and then had complicated code that would parse the strings to perform math on the timestamps. The refactor involved replacing the strings with a defined type. Not only was it faster, the code was easier to follow because the timestamps were well encapsulated.