I'm not aware of any credible engineering effort that only does that.
1) Your tests are just as likely to have bugs anyway.
Yes, but only with P(test_bug). We see code bugs with P(code_bug), and if there are tests covering all those pieces of code, the final probability of bad things shipping to production is P(test_bug) * P(code_bug)
Obviously, it's an overly optimistic assumption, but tests serve as one additional layer in a "defense in depth".
2) The 'bad' bugs are logic bugs - if your logic is wrong, your tests are wrong, so you are testing the wrong thing.
If your logic is wrong, your architecture is likely to be wrong, too. If your basic assumptions are wrong, your code will be too, no matter what.
3) Users often do things you didn't plan for.
Yes, and architecture isn't going to save you from that either. (It helps, though. Planning to minimize state is a good idea :)
4) [...] will make it so you don't need to spend months re-factoring in the first place.
Which is a great strategy - if you can assume your requirements never change. If you work in a field like that, excellent. Most of us, however, need to deal with a rapidly changing field.
software engineering in general needs more architecture
Good software engineering has architecture. Tests augment it. How much architecture you create up front, how much you create on the fly, and how often it changes depends entirely on the field you work in, and how much resources you can spend on an issue.
I'm not aware of any credible engineering effort that only does that.
1) Your tests are just as likely to have bugs anyway.
Yes, but only with P(test_bug). We see code bugs with P(code_bug), and if there are tests covering all those pieces of code, the final probability of bad things shipping to production is P(test_bug) * P(code_bug)
Obviously, it's an overly optimistic assumption, but tests serve as one additional layer in a "defense in depth".
2) The 'bad' bugs are logic bugs - if your logic is wrong, your tests are wrong, so you are testing the wrong thing.
If your logic is wrong, your architecture is likely to be wrong, too. If your basic assumptions are wrong, your code will be too, no matter what.
3) Users often do things you didn't plan for.
Yes, and architecture isn't going to save you from that either. (It helps, though. Planning to minimize state is a good idea :)
4) [...] will make it so you don't need to spend months re-factoring in the first place.
Which is a great strategy - if you can assume your requirements never change. If you work in a field like that, excellent. Most of us, however, need to deal with a rapidly changing field.
software engineering in general needs more architecture
Good software engineering has architecture. Tests augment it. How much architecture you create up front, how much you create on the fly, and how often it changes depends entirely on the field you work in, and how much resources you can spend on an issue.