No, you're not understanding the context in which to apply this; this isn't something you do at the app level, it's something you do at the feature level. The app is always well structured and well factored, but when adding a feature, you start dirty, get it working, then clean it up, and then optimize it if required, then move on to the next feature. This model works for all sized projects, all the time. The point of doing things dirty is to avoid premature architecture/abstraction which is a bad habit many programmers have.
Now if you have the experience to know beforehand what abstractions you need because you've done this many times, of course you can start cleaner; you do things dirty when you're unsure of what abstractions you might need and don't want to get hung up in trying to invent an abstraction before you know you need it.
It depends on your knowledge/experience levels. A very experienced develeoper's prototype would likely be much better than a junior's production-ready version.
Short version rephrasing of the rule: put a prototype into production.
You can see how it is obviously bad.
Typically cleaning up a dirty version is VERY hard. Takes much more time than rewriting assuming you wrote proper functional tests.
Likewise you cannot make a truly wrong design really fast without redoing it.
I would flip the rule on the head: design so that it can be made fast, is easy to get right, therefore will work.