Я бы даже слегка расширил ответ.
Верхнее значение количества транзакций, которое в состоянии обработать дисковая подсистема - определяется количеством iops, которое эта система в состоянии выдать на диске, где лежит log файл базы данных.
Т.к. ни одна транзакция не может быть зафиксирована, до тех пор, пока запись о ней не будет сделана в логе (точнее - даже несколько записей), то количество insert/update/delete в секунду - не может превышать количество iops диска логов ( /3, примерно ).
Т.е. если у вас логи лежат на одиночном 5400 ВД грин, то количество транзакций, которые вы выдавите из системы - где то 50-60 в секунду.
Но это все - без кэширования.
А запись в лог - как раз и происходит без кеширования, с флагом "не кэшировать" для системы, и командой "не кэшировать" для контроллера (он ее, впрочем, может игнорировать, и, скорее всего, в принудительном write back - проигнорирует. Но это его дело, у него на это батарейка есть на кэше).
Так вооот... В режиме "отложенной устойчивости", мы просто разрешаем системе кэшировать запись данных в лог, что позволяет ей данные, предназначенные для записи - пакетировать, и отправлять на диск в рамках одной команды. И, соответственно, снижать ОБЩЕЕ количество операций ввода-вывода, которые порождаются транзакциями. Теперь 10 (предположим) пакетов о начале транзакций, произошедших одновременно - это не 10 операций ввода вывода, а одна.
Ну и, соответственно, количество обрабатываемых транзакций в секунду - растет пропорционально.
При этом скорость обмена с диском, скорость выполнения самих команд - остается прежней. Одна фиксирована железякой, другая - нууу... структурой и командами БД. Но ожидание на фиксацию изменений в бд - сокращается.

Яркий пример - База на 1С.
Любимый прием работы одинесников - "от записи к записи". Они открывают курсор на миллион записей, и начинают по одной апдейтить. Сутки.
Включаем ДД - получаем апдейт за час. :-)))
И непредсказуемые глюки, если система уйдет в ребут.
... но это - не точно :-)))