I agree with some, but not all of the conlusions. There is value in standardizing the things that it makes sense to standardize.
With that said, first this is an attitude that can be taken too far easily, and second I think that some of the anologies used to draw the conclusions are flawed. As to the attitude for standarization, I certainly agree that the more that can be reasonably standarized the better. It helps everyone understand, it helps assimilate new objects rapidly, and it generally improves quality. But not everything can or should be standarized. You certainly could use an artificial key with the same name for all tables, but this comes at a price (Joe Celko discusses it many times). But if you try to use a natural key for all tables you will run into some where the natural key is composite which creates its own problems. I think it makes sense to decide, if not table by table, then certainly database by database whether you want to use artificial keys. I find the idea of standardized audit fields even worse since they do not make sense for all tables, and unused fields tend to create confusion and waste.
As to the comparison with the auto industry, I find it flawed. There the goal is precisely to mass produce large numbers of nearly identical products with interchangeable parts. It makes tremendous sense to standarize virtually everything in that and keep producing them. But no two software projects are absolutely identical (if they were, you would just copy the first one and be done with it). They must be produced adjusting for the unique situation at hand and the unique requirements of the task, unlike engines where you want thousands that are absolutely identical. That of course isn't to say you can't standarize and reuse a lot, must CRUD apps especially on the front end side are very similar, and good libraries are a move towards standardization, but you can't standardize everything for software.
Another thing to point out is that most assembly line workers are not the same as craftsmen. They just repeat the same thing over and over without trying to optimize for absolute performance. Where you see craftsmanship in that arena still is in custom jobs or after market customization. I recently had my motorcycle mechanic install modified foot rests on a motorcycle that wasn't really designed for them. As part of that, he custom built an extender to move the break pedal up and forward based on the bike, the foot rests I had chosen, and me. That (although simple in this case) was an example of custom craftsmanmship based on specific conditions. Software creation is much closer to that situation, then to assembly line workers repeating the same motions over and over.
Timothy A Wiseman
SQL Blog: http://timothyawiseman.wordpress.com/