This is good advice in general, and so it amuses me when i come across problems which invert this order. Now and then, you can say "if we could do this thing that currently takes time T in T/100, it would be a game-changer" - it would enable whole new approaches, businesses, etc. In that case, your primary goal is to make it fast, and if often doesn't matter if it crashes, fails, or gets a slightly wrong answer 10% of the time, so you start by making it fast, then improve the code, then work on the improved code to make it reliable.
No. It might take someone else time T to do it, and we don't do it at all. It might take another program, whose codebase we are not going to touch, and which does it in a different way, time T to do it. In the cases i am thinking about, this was a new program, written from scratch, which did not go through a "make it right" phase before being made fast.