шаблоны проектированияСколько ни видел шаблонов (паттернов) проектирования - все они строятся на основе классов, темплейтов и перегрузки операторов, и соответственно все они под С++.
А есть ли вообще паттерны проектирования без всего этого под С?Встречный вопрос: что мы понимаем под проектированием в "чистом" C? Проектные решения (и их шаблоны), как я это понимаю - способ решать часто возникающие задачи масштаба больше, чем самая большая структурная единица языка.
То есть, для C набор методов, который, по соглашению, принимает первым аргументом указатель на одну и ту же структуру - паттерн проектирования. Создание функции вида Library_GetLastError() - паттерн проектирования.
Ну, или так:

шаблоны проектированияВот меня тоже интересует, по определению и по смыслу шаблоны проектирования неразрывно связаны с ООП?
Понятно конечно, что можно в функцию передавать структуру, или в структуре держать массив указателей на функции эмулируя ООП.
Встречается ли в классической литературе их описание в отрыве от ООП?Нет "классической" литературы. Книга "банды четырёх", от которой обычно отсчитывают выделение шаблонов проектирования как чего-то отдельного от программирования вообще, была издана в 1994 году. Поскольку последние 20 лет высокоуровневое проектирование в основном имело дело с объектными языками, натурально, изучались шаблоны для объектной парадигмы.
Это же не какая-то штука, которую в один прекрасный момент взял и придумал кто-то конкретный - это просто общее название для определённого класса решений. Скажем, рекурсия - это тоже род архитектурного решения (по проектированию функции), в C обычно неудачного. Если покопаться в старых проектах, которые писались преимущественно на C, в них наверняка можно будет выделить какие-то общие архитектурные приёмы; эти приёмы можно будет описать и назвать паттернами проектирования процедурных языков.
Вопрос только... оно надо?

шаблоны проектированияА шаблонами проектирования называют best practices для ООП потому, что в именно в ООП легко выделяются общие принципы построение кода или просто потому, что большинство программ пишутся на ООП-языках?
Почему то нигде не встречается нечто подобное для процедурных или функциональных языков.Скорее второе, как мне кажется. "Общие" принципы - всё-таки понятие слишком аморфное, разные парадигмы высвечивают разные грани. На основании ООП мы умеем строить большие системы, в которых регулярно возникают архитектурные задачи; в прочих парадигмах на сегодня (насколько я себе это представляю , точных данных у меня нет) обычно отсутствует или первое, или второе. Скажем, логическое программирование использует заметно иные принципы и может применяться для выстраивания достаточно крупных систем... но задачи их построения обычно не называются "архитектурными".