Well I disagree your point of view.
You didn't define the scope of the applications, the dimensions of the tables and the no. of transactions per second.
I'm in a position where we're using SQL for telephony platforms, not for groceries, and believe me, the overhead introduced by the indexes/keys/any kind of contraints slows down the insertion so much that you cannot follow the platform (the calls/SMS/MMS events).
So please be more carefull when generalizing your afirmations. Don't give me advices on how to do it, we've tested everything that can be tested on mostly all the hardware you can imagine (i.e. HP SuperDome, RAM disks and so on).
So my conclusion is:
When your applications:
1. Search atomic data not use whole bunches of data from your tables
2. Make a lot of searches, insert at slow rates (human interaction or low numbers of rows/second)
3. Make udates, deletes (more atomic than globals)
Than indexing is a must.
If you intent to:
1. Basically append (insert) at very high rates
2. Almost always use the whole volume of data, not atomic pieces
3. Delete/Update the whole tables or very large volumes of rows in your table
4. Make less searches/selects (daily reports, weekly or monthly)
DO NOT index or make the indexes just before youre consulting the data and destroy them immediately after!