What about the "lose a sale" part? What sales?

What am I missing?

Don't lump specs/design documentation and user documentation together. They are completely different.
The design documentation should complement the code and give a new guy the high-level overview he needs to know where to start reading the code. Less documentation is good in exactly the same way that less code is good. This is about maintainability.
The user documentation is like the functionality of the code once it's running. More documentation is good in exactly the same way that more functionality is good. This is about usability.

Don't misunderstand me, I'm not saying that smaller code is always better or that more features are always better. It's the difference in considerations that separate the two types of documentation.

I also believe it squeezes the most out of developers (for better or worse). The pressure is on all the time instead of just at the end of the project and I get the impression that pair-programming drains your energy quicker than working on your own because you spend more time being focussed.

I can't tell if your claim is about agile methodologies or not, but in case it is:

The agile methodologies pick the requirements that are most solid and independent to implement first and only refine and implement the others later.
The hope is that the latter set of requirements will be easier to nail down by the time you need them. If they were to change between the start of the project and the time you needed them again, that change would not have cost you anything.
What they do not do is encourage you to make things overly generic in order to already capture future requirements.

So they do intend to reduce the cost of late changes, but not by spending more up-front.

And the fact that even their menubars have menubars. On a single screen there must be 5 or 6 places where you have some kind of menu.
Oh and what about the fact that there are menu items for options, for settings and for preferences, as well as options, settings and preferences that are not located under the options, settings and preferences menu items.

I'm from the Netherlands and I was taught the countries of the world in elementary school. We were not taught the states or provinces within each foreign country. Was that any different where you went to school?

There's a limit to how much error handling code makes sense.

If you want to handle every eventuality gracefully, your code will be much more complex because of all of the error handling paths. This will in turn increase the chance of introducing bugs caused by limited understanding of the code (most likely by others or by you a long time from now).

In my opinion there's a balance to be struck and I usually stop at the file or component boundary. If it comes from the outside, deal with it. Internally (e.g. static functions), use asserts to check if you messed up.

Oh, I guess you just write your code once and nobody will ever modify it?

Asserts should stay in there just in case you or anyone else decides to break any of the invariants in the future.

How about this one then, from 1991: http://www.imdb.com/title/tt0103239/

The article calls it "a (...) partnership to develop EUV". That's not just product development.
5 years is not a long time at all if you include the research period (and I don't mean general research in the area, but focused research/feasibility studies).

is full of shit.

I use scroll lock when I see something unexpected during the boot process and want to have some more time to read it before it scrolls off the screen.

Its vim emulation is not complete and consequently pretty annoying.