As others have noted, getting it right the first time is of course cheapest. But i would also point out that any programming construct whatsoever falls somewhere on the spectrum of pattern-anti pattern. You're either implementing something in an orderly way or not; 'goto' infested code is following a pattern, it's just something that was recognized early on as potentially harmful. But note that all code boils down to jumps and branches at some point in the compilation cycle. There's nothing inherently wrong with jumping: it just ends up making larger projects more difficult to understand.
It is easy to get misled by patterns that appear trivial for simple use cases. As soon as you start needing more flexibility, most brittle patterns will degenerate into anti patterns. So my rule is to only write code I can understand and have a reasonable chance of debugging. If I decide to apply a clever pattern blindly, I have to be at least as clever as the pattern-code in order to debug it. So the key is just making sure you're isolating and utilizing patterns that apply specifically to your problem directly, that you're approaching the problem at the proper level of abstraction, and that you can understand and debug every line in your code.
One key here is striking the right balance between short- and long-term requirements. Keep in mind that writing good code quickly is something that starting from well-understood patterns can certainly assist in -- spaghetti code may seem faster, especially at first. But you will quickly see the limitations of anti patterns in any larger project, where decomposability, modularity, etc., become incredibly important.
