Часто встречаю функции в исходниках библиотек, который "завёрнуты" в другие функции. непонятно, зачем так писать? какой в этом смысл?

Пример:



причём функции находятся в разных *.c файлах

Когда библиотека (программа) кросс-платформенна, и действия функции atan2sp_i зависят от конкретной архитектуры.
Такое можно часто видеть и в U-Boot и GNU/Linux, например функции работы с прерываниями (указание обработчика прерывания конкретной линии или периферии). Вроде как и простое действие, но очень зависит от архитектуры. А когда пишите свой драйвер (программу), то не лезете и не оперируете отдельными битиками а юзаете страндартную функцию (которая в свою очередь вызывает функцию выполняющую всю грязную работу) Вообщем как-то так

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

чисто организационный. причины так организовывать - некое логическое деление кода на уровни и абстракции.

Видимо создают интерфейс с библиотекой. Легко поменять если надо. Добавляется гибкость.
Я всегда использую вызовы mallock() и free() не напрямую, а опосредовано, но чаще использую макроподстановку, а не дополнительную функцию.

Такой подход позволяет легко модифицировать вызов для поиска утечек памяти. Хотя многие ОС позволяют сделать это более изящно.

Еще предположение. Одна и та же функция может сделать работу для разных типов данных, но для разных типов данных нужны разные функции.