Optimisation vs Buggy software
I agree with the author. Don't optimise until the end, only allow experts to play, and put clear explanations around the reason.
Having said that, I think some people may be getting hung up on the word 'optimisation' and think it equates to any change that improves the responsiveness/performance of an application.
If someone implements the wrong algorithm to solve a problem, or invents a problem, putting it right isn't optimisation it's bug fixing.
Example of evil optimisation:
A car race timing system back in the darkest 80s was using an IBM-XT to display the results as the cars crossed the line. To avoid using a multiply the really, really smart guy wrote 15 lines of hand crafted assembly that was smacked into the middle of the C. That code wasn't touched for 10 years, until I came along as a grad, and asked 'What does that do?'.
Not one person working in the company knew, I spent 3 days 'un-optimising' the code, which opened the code up to the compilers optimiser, and thus fixed a accuracy problem we were having. The smart guy solved the right problem on the day, but forgot to tell anybody.
On the flip side:
Big error reporting system was sorting the displayed list (nice really fast binary search) list into time order every time a new entry was added, the fact that the list was already in time order, and that errors came in in time order seemed to have been missed by the developer. Removing the sort was not optimisation, it was bug fixing, the code was more maintainable, worked as specified, and had adequate performance.
For my mind 'optimisation' is the process of breaking code maintainability for the sake of performance.
Improving the performance, maintainability and efficiency of an application through fixing broken code and improving architecture is a very different beast.