The problem with point 3 is that once you start with a bad draft and everyone starts working on it you're kind of locked in to its trajectory, even when it'd be a lot better if you were to do it another way. You can't start from scratch even if you're feasibly within the window to do so, because now the work has started.

But that is still better than nothing at all, which is the point.

The people you want (or want to be) are the engineers who are smart and experienced enough to get a first draft down that is pretty much right without a long drawn out process of figuring out the best way to do X, Y and Z with all the lengthy ADRs, discussions, debates, POCs, revisions etc. over and over again. That may be necessary if you don't have people in the room who know what they're doing and have the intuition through deep experience to choose good tools, patterns and abstractions at the start. Begin closer to the target, rather than far away and iterate to it.

I think it depends on the team.

Some teams I’ve been in, we could go “this is shit, we must be doing this wrong” and we’d go back to the drawing board without blinking.

Other teams, just getting _something_ going, even if it was garbage, was a enormous achievement, and saying it was bad and that we should start again would be a recipe for disaster.