I write dozens of shell pipelines every day. Some graduate to actually being saved in files and cleaned up a bit. Some of those start needing new features, and end up rewritten as quick and dirty perl scripts. A few of those see constant use in more and more circumstances and end up accumulating an ever larger number of features. Once that program grows large enough, it'll become obvious that it'll become unmaintainable at some point. And you can either evolve that code into a less crappy state when other changes are made, or you can rewrite it from scratch.
And the thing is, you can't really know in advance what kind of a program a given problem really warrants. Is it shell pipeline that'll only ever be run three times, or will it end up as a core component of somebody's workflow. Since you can't predict these things, you have to play the odds. If most programs end up as important tools, it'd be insane to risk the need of multiple rewrites. While if most programs end up just gathering dust somewhere, it'd be insane to polish them to perfection before committing. And even if "nothing lives longer than temporary code" is a nice soundbite, I don't actually believe that for a moment. I'd bet that most temporary code actually dies almost instantly. It's just some kind of observation bias.