Сложившийся в юниксах (да и не только) алгоритм "одна программа генерирует человекочитаемые данные - другая программа их парсит" напоминает наших дорожников, которые старательно кладут асфальт во время снегопада (на обледеневшую землю и слой снега), а потом перекладывают его летом (разумеется, под проливным дождем, на размокший песок).

Фактически, при преобразовании данных в "человекочитаемую" форму теряется информация об их структуре (в частности, о разделении между полями). grep, sed, awk - не более чем костыли, которые предназначены для попыток восстановления структуры данных (выделить конкретное поле из записи, отвечающей заданному условию). При том, что в "машиночитаемой" форме такой проблемы нет как класса - почти любая модификация SQL позволяет играючи решить то, для чего "опытные админы" громоздят на bash, sed и awk многоэтажные карточные домики (рушащиеся от малейшего изменения синтаксиса исходных данных, или просто криво написанного шаблона, не учитывающего некоторые неочевидные случаи).

Гораздо более правильным и логичным было бы хранить подобные данные в машиночитаемом виде (например, SQLite или его NoSQL аналоги), а в человекочитаемую форму преобразовывать только по запросу администратора и при генерации отчетов. Помимо устранения проблем с парсингом, это дает и многие другие фичи - возможности индексирования, сжатия, избыточного кодирования, криптографического контроля целостности и т.д.

Разумеется, вышесказанное не относится к тем ситуациям, когда нужно распарсить не вывод программы, а текст из внепрограммного источника - в таком случае, конечно, sed и awk будут на своем месте. Ну а применимость их для не-парсинговых задач - это уже вопрос личного вкуса.