..the doublewrite buffer is actually a benefit. Beyond guaranteeing
that pages are recoverable, it also reduces the required fsyncs. Without
it, each page that is written to the tablespace would need to be
fsync'ed. With doublewrite enabled, a chunk of pages is written to the
doublewrite buffer then 1 fsync is called, then pages are written to the
tablespace and then 1 fsync...

While I'm completely agree with Mark that we absolutely need a recovery
tool to be able at least to repair what is "repairable" (nobody
protected from an accident :-)). But on the same time I was curious to
measure the doublewrite buffer impact under a heavy read+write workload.
I've noted it in my TODO list, but only recently was able to test
XtraDB, MySQL 5.4, InnoDB plugin-1.0.4 and MySQL 5.Perf with doublewrite
enabled (before I run all my tests with innodb_doublewrite=0only).

For my big surprise with innodb_doublewrite=1setting I observed no performance degradation (or
near) on all engines! Even the higher rated 5.Perf was still able to
keep its TPS level. From the I/O level a flushed volume become slightly
higher, but nothing important as you may see from the following graph
(the first part of the graph is representing the workload with a
doublewrite off, and the second one with a doublewrite on) :

I would even say it brings more stability to the workload! And knowing
it also brings more data security - it should be considered as a must
option :-)

But now I'm curious : what kind of impact in any other cases was
observed by you?...