Я использую "отложенную устойчивость" :-) в ETL задачах.
Только не форсированную, а управляемую.
Т.к. новые данные грузятся в рядомстоящие секции, а потом подменяются свитчем, то проблема потери данных при перезагрузке или сбое не стоит вообще. Все равно данные заново перезагружать.
Скорость загрузки выросла в 4 раза. Если раньше типовые 10 млн. записей грузились час, то сейчас - 15 минут.

Стандарты, хоть и дешевле, обладают "особенностями", которые сразу начинают выпирать.
Во-первых, 128 Гб ОЗУ - откровенно мало.
Это значит, что суммарный объем баз под OLTP нагрузкой у вас будет всего где-то гигабайт 500, прежде чем пользователи начнут жаловаться на задумчивость БД.
Опять же процессоров - всего 24. Ну, если в базу не летит ничего сложнее чем select * from tbl where id=1, то не критично, а если разработчики предпочитают изъясняться в стиле "Воины и Мира"?
У меня есть OLTP система, где типовые запросы - строк по 500, а запрос, формирующий "оперативную отчетность" - немного не дотягивает до 8 тыс. строк. Запрос. Один. Но не будем о грустном.
Онлайновое перестроение индексов - нужно не часто, но иногда бывает.
Ну и с управлением ресурсами и аудитом - всё сильно лучше.

Поэтому если речь идет именно о 2 энтерпрайзах против 4 стандартов - я однозначно выберу 2 энтерпрайза. Разумеется, если мне не придется оплачивать их из своего кармана.
:-)

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

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