Actually I find that all too many schemas have been developed by people who either don't know or don't want to be bothered to follow standard design principles. Designers who are trying to get the design correct are sometimes unfairly labelled as the author has done above, using words like "obsessed" and "fusses." But when the design has issues, the successors to the designer are usually the ones who pay for it.

The decision as to whether a table should receive a synthetic key, for example, are not is very important in an OLTP design. If the table should have been keyed on an existing column or columns, it can easily cause problems down the line.

As for the length of fields, I've seen fields for the city name of varchar(100) and state for varchar(50). Restricting these to a more realistic size is one step towards helping to ensure the proper data gets into the field.

Historical analogies are often risky. Comparing Honda's construction of an engine to applications is shaky. Using a race as a factor shows that under extreme conditions, Honda does better than others. Most applications (or engines for that matter) don't function under extreme conditions. For those applications that do function under extreme conditions, it's even more important to get the design correct, with the understanding that correct changes as the business changes.

I think the article would have been much more effective had it just focused on the product rather than negatively portray people who are trying to do their job diligently.