U235> Нет. Стало на порядок лучше чем было. Просто появились новые проблемы. Например вопросов скорости и оптимизаций работы поиска просто не существовало в бумажных журналах: с какой скоростью листаешь, с такой и ищешь 
Совершенно правильно!
СУБД
упростило написание приложений наверное на порядок
Простой пример 1: АРМ какого-нибудь клерка, скажем десяток форм.
Если ранее это хранилось скажем в текстовых файлах или в двоичке, то
а) загрузка/сохранение лежала полностью на программисте - ручками с файла
б) поддержка целостности данных - лежала полностью на программисте - руками в коде!
в) поддержка скорости - например индексация - лежала полностью на программисте!
ага - бери учебник и давай cоpy/paste - индексы по полям 1,2,3 для массива А, индексы по полям 1,2 для массива B, индексы по полям 2,3 для массива C -
все руками.
Причем если база - один двоичный файл - это вообще отдельная песня - надо его разбить на части и раскидать по формам. Отдельная песня - запись изменений, если скажем поменялось только чуть-чуть в середине.
С базой - форме только надо соединение с базой. Код формы может быть очень простым - вызов трех процедур на базе по необходимости - get, insert, update для данных формы.
Индексы - в базе
Целостность - типа значений по умолчанию или ограничений ( Constraints ) или ссылочной целостности ( Foreign Keys ) - все в базе.
Кроме того, база позволяет разрабатывать приложение инкрементально - отладил одну форму, берись за другую, остальное можно не трогать - что в принципе невозможно при реализации базы одним двоичным файлом - его постоянно придется менять.
Причем, при желании, фронт-энд можно вообще сделать легковесным и динамически настроить все формы с базы - я так делал.
Простой пример 2: использование базы как промежуточного хранилища для оптимизации реализации.
Так было в Транзасе. Задача очень простая - есть аэронавигационная ARINC база с тремя типами объектов: точечные, кусочно-линейные и площадные полигоны. Каждый объект с метаинформацией ( название, код, высота, срок действия и т.п. )
База поставляется в текстовом виде в заданном формате - как было сделано еще на мейнфремах.
Задача - выцепить из нее данные и разбить по файлам карт - скажем с разрешением 15 на 15 градусов ( по широте и долготе )
Ранее эту задачу решил специалист с образованием по аэронавигации и знанием программирования на уровне Фортран-4. Код был ужасный, слабо структурируемый, поддержка ужасная, делалось долго: на Пентиум-166 базу раскидывали по картам где-то день. Причем отладка была тоже ужасная - ввиду тормознутости работы. Самый трудный момент - разбить один площадной объект если он переходит границы нескольких карт - от двух до четырех - он должен быть на всех.
Я постоянно повторял руководству что надо это переписать на СУБД - неважно на какой.
А повторял часто - скажем пришли новые данные, запустили разбиение, а ночью оно упало с ошибкой.
В конце концов меня послушали и так и сделали.
Причем сама разработка заняла не так много времени, по сравнению с тем, сколько было убито не предыдущем решении. Только ее доверили уже другому человеку, со знанием ООП и БД. Реализация легко разбилась на части и отлаживалась прямо по базе.
Ускорилось это на порядок минимум - генерация всей базы с раскидыванием по картам делалась на том же железе менее часа.
СУБД - даже в случае простейшей SQLite -
сурово упрощает разработку