Оба способа работают, однако, подход с использованием структуры немного "проще" использовать. Вам (или тому, кто это будет использовать) также не придется беспокоиться о передаче правильного размера, и совсем не обязательно его организовывать. Вы просто обрабатываете одну структуру или один логический объект. Если вы разделите все на части, вам придется обрабатывать как данные, так и метаданные самостоятельно (т.е. рассказывать / передавать данные и измерения).
Есть ли недостаток в использовании структуры? Не то, что я знаю (кроме необходимости обрабатывать еще один указатель). Однако есть одно огромное преимущество: используя структуру, вы можете использовать функцию, которая также разделяет данные и метаданные (передавая элементы структуры, а не указатель на структуру). С другой стороны это не так просто.
Что касается "оно того стоит?" учитывая, «должен ли я сделать это для организации?»: сделайте это, если группировка логична. Многие оконные API-интерфейсы работают со структурами таким образом, но я не большой их поклонник, если группировка не логична или создает дополнительные «трудности». Другими словами: не группируйте ваши параметры в структуру, если они не связаны или если пользователь, скорее всего, не будет иметь их в этой форме (т.е. они сгруппированы только для этого вызова).
Edit:
Как пример:
- Я бы сгруппировал данные вашего примера, так как ширина и высота принадлежат матричным данным, и они связаны (плюс они могут использоваться в других функциях таким же образом).
- Однако я бы не стал группировать такие параметры:
write_log(LOG_INFO, "All data has been processed");
Добавление здесь структуры добавило бы сложности, которая не требуется. Вполне вероятно, что эта группа данных не будет использоваться где-либо еще, что усложнит вызов функции (так как вам придется сначала создать структуру).