Myth of Maintainability/Performance Trade-off

Reading through blogs and technology books, I remember an architect mentioning that he always liked to build code according to criteria in this order:

1. Functional: It must do the job or else it is useless.
2. Maintainable: Code lives most of its life in maintenance mode, so we may as well make it maintainable to ease performing code changes, bug fixes, and feature additions.
3. Performant: If it does not get the job fast enough, why bother use the program at all?

However, I have seen developers struggeling with performance issues trash maintainability in favor of performance, not believing that they can come up with a solution that would achieve both.

I beg to differ. I believe that with today's hardware, no matter what the performance optimization is, it can almost always be abstracted and encapsulated in a way that would keep the application layer code clean. I notice that programmers who end up achieving both maintainability and performance are the ones that keep both goals in their head while solving performance problems. On the other hand, those who soly focus on performance may end up trashing maintainbility, and they feel justified and happy about it, possibly cursing at frameworks, not knowing that they probably could have had both performance and maintainability if they made that a goal instead of taking a defeatist attitude towards it.

If you could think of a scenario in a recent project where a lot of maintainability had to be sacrificed for performance, please share in the comments area for discussion.