Since 99+% of all startup ideas will fail, it makes no sense to invest and optimize upfront. If your startup runs into scalability problems, you can always fix those later. You should consider the first version a throwaway. More than likely, your investments will be wasted. Even if your startup succeeds, it will often be a pivot away from the original mission.
The only case where I would say this doesn't hold is your security/privacy architecture. You don't want to fix this later after you've let your customer's data be stolen, you want this done right up front. You can rewrite everything else about your product, except for the things, which if they go wrong, will result in people being hurt materially or physically.
If you start out knowing that you are writing something that will be trashed, why would you invest yourself in it? It's hard to tell someone to build something that will be thrown away; to trade the time they can never get back for something that will most likely fail. That will almost certainly _not_ get their best work - which means your odds of success go down; perhaps drastically. And if the first version DOES happen to work, you still have to throw it away at some point and start over (or else live in pain for the life of the product). Either way; you loose.
Now think about the approach where you take the time to think through your ideas. Where you expect the best from your people right from the start because you're all building to last. When you earnestly expect the best of people, they generally give you that (or close to it, at least). You get a better result. So then the first version doesn't work. But you've learned a lot, because the thought process you went through taught you things; things you took the time to learn. Things you can leverage in your next venture; things that will speed it up, make it stronger, get it quicker. But what if it worked? Now you're not fettered with the task of rebuilding what you've just built because what you have is solid. It can be built on. So that momentum you have as the first version works can be leveraged into the second, third and fourth versions. And momentum means something; it means happier employees and - ultimately - better returns.
The former (get it quick) is (for the most part) the world of today. The latter (get it right) was the world the author remembers - and pines for.
Cutting corners during development may build technical debt, but for the first N iterations, it also saves time. The argument goes that it's more important to get more versions in front of your customers than to build the perfect codebase off the bat.
Also, in any startup, you're going to need to significantly adjust the codebase as your business changes products (pivots). All the effort invested up front on a feature that isn't relevant is essentially wasted.
Speed of iteration is the primary objective (to people who think this way).
If you /don't know/ if there will be any customers for your product (no matter how well-built it might be), spending time and money on building a very solid v1 is a waste. Sure you will have experience that you can leverage in your next venture, but that's an extremely expensive way to get it. And if you're bootstrapping, or have hired other people, you're potentially spending the financial stability of you or your employees to get this experience.
If you /do know/ you will have customers (either because you're sure it's a problem people have, or you've got people giving you money for basic R&D without any guarantee of returns), then I completely agree with you and the author -- build the product right and it will pay dividends later on.
In the prototype-then-throw-away model, you might not get the engineers' best development work, but you will get the best brainstorming and design work, because everybody's comfortable adjusting the product until they're confident they have something that people want. If you marry yourself to it beforehand, if you commit people's livelihoods to it, people will naturally try to rationalize what they're doing because they're committing so much to it, even if it's wrong. And if you've got the smartest people working with you, they'll be incredibly good at it. This creates a much bigger problem years down the line if it fails.
[1] https://archive.org/stream/mythicalmanmonth00fred#page/114/
This basically boils down to: why would you make a high-risk bet? The answer: Because they sometimes pay off big.
I like building things to last. But building something to last when odds of success are 50 to 1 against is foolish. If you are trying to test a startup idea, the only sensible approach is to bet the absolute smallest amount necessary to find out if the idea is worthwhile.
I've built great systems for ideas that didn't work, and it sucks. For example, in 2004 I put together a team and spent 9 months building an awesome implementation of an excellent idea that was just 5 years too early. We were all really proud of our technical work, but since we ended up with a trivial number of users, it was all, in the end, wasted effort.
Later I realized, thanks to people like Eric Ries, that the thing to do early on was to invest just enough to see if there was something to the idea. Most things won't, which means you save enough time to rebuild the few that do properly.
The "think through your ideas" thing is a false hope. You can only think so much about limited data. People can be just as happy working on something they're planning to throw away. Artists often do plenty of sketches before they do the real one, and software developers can do the same.
https://gist.github.com/philfreo/7257723
https://gist.github.com/nikcub/3833406
There are plenty of people in this industry who would have told you this code wasn't fit for production.
People frequently overestimate both what's needed to build commercially-viable solutions and how easy it becomes to recruit the right people to improve (or reimplement) poorly-architected solutions if they become popular.
Getting a good idea is usually harder than getting the tech right. Being able to quickly make prototypes is the most important thing in a start up.
FYI I'm not a "brogrammer". I work at a large established company and one of my main jobs is making systems work at large scale. But that's not what you do when starting a company. If you make it you can sort out those issues later.
If you optimize more than you need to then that is premature optimization. But if it takes 5 seconds to load a page (or more) then any level of success will kill you and that's bad for business. You need to scale just ahead of the needs of your users. Too much and you're going down the premature optimization rabbit hole, too little and you'll end up with angry users and competitors will likely eat you.