Ну и чем тебя тут спасла бы самая золотая субд?
Давай орацкл запустим кривыми руками того же васяна, а потом, глядя на неустранимые ora006, будем всем рассказывать, какой орацл плохой. Или попробуем поднять рухнувший postgres (вот кто умеет крэшнуться сам по себе с оригинальными последствиями), или вон могу подарить снапшот mysql в принципе не подлежащий восстановлению не смотря на lock database в момент снапшота.embedded db не позволяет тебе изолировать критичную часть "приложения" там где к ней нет доступа у васянов ни в плане администрежа, ни в плане гуанокодинга? Ну да, тоже мне, открытие.
Ну меня это как-то не беспокоит, я десять лет с такими имел дело на заре карьеры - начиная от уродов типа dbase и заканчивая вполне приличным clarion (да, они все embedded, правда, своеобразным способом). Ничуть не сложнее и не неудобнее чем орацл - скорее наоборот, ибо предсказуемее. Бэкап при этом никто не отменял.
В конце-концов, в XXI веке все еще кое-где у нас порой не абсолютно все на свете хранится в таблицах - как тебе твоя крэшащаяся программа например в обработке денег смотрится?
Или даже банально твоей почты - когда потеряет письмо от твоего нигерийского дяди, завещавшего три миллиарда не нигерийских долларов первому, кто на него ответит? (Ну ок, от работодателя с предложением интересной работы в хороших условиях - не получив ответа, ставящего галочку "соискатель не имеет нужной квалификации чтобы хотя бы почту читать")
При этом, повторяю, именно sqlite имеет максимум средств для восстановления в этой ситуации, васянами не воспроизводимых на коленке - о чем я каждый раз получаю напоминание, перезапуская фуфлофокс. Эти дятлы неосилили sqlite, ага, они умеют ведь кодить только в "html+js" и еще вот немножечко в md. Поэтому то что их предшественники хранили в ней, у них перенесено в нескучный json. Без средств сохранения целостности, восстановления и хотя бы проверки.