Использовать Qt только ради механизма сигнал-слотов?!

Механизм сигнал-слот - это паттерн наблюдатель, который можно реализовать на чистом С++. Примеров масса, сторонние библиотеки для этого не требуются.
Сложнее будет в случае использования многопоточки, но и там всё можно решить.
Если тащить QT только ради этого, моё мнение - это слишком избыточно.

Если нужна сторонняя библиотека и не хочется изобретать велосипед - boost signals2 вам в помощь.

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

Сигналы и слоты есть в boost и они там на шаблонах, в boost слот ещё может возвращать результат в отличие от Qt. Но ни раз не сталкивался с ситуацией, когда бы мне это требовалось.
При этом Qt "вроде как" более потокобезопасный, а также может вызывать методы и сигналы по имени функции за счёт мета-объектной системы в других потоках, опять же потокобезопасно вызывать эти методы.
Вполне возможно, что в вашем проекте именно такие мета-объектные хаки могут присутствовать.

Также boost взял концепцию сигналов и слотов именно из Qt.
При этом в Qt как мне кажется более удобно реализована рабочая петля приложения. Нет необходимости очень много костылей для этого писать, да и connect сигналов и слотов будет поудобнее и работать будет более предсказуемо за счёт очереди вызовов сигнал слотовых соединений.

Так что в принципе ничего плохого в использовании Qt ради сигналов и слотов не вижу, тем более что это один из главных аргументов, на мой взгляд, чтобы использовать сигналы и слоты, кроме кроссплатформенности GUI.

Коллбеки работают немного быстрее сигналов и слотов, это даже в документации написано, но эта разница настолько незначительна, что не стоит внимания. При том что сигналы и слоты явно удобнее в использовании. Однако при разрастании программы порой становится сложнее отслеживать, откужа именно прилетел сигнал, но я сейчас говорю о действительно больших проектах, например, на миллион строк кода. В более мелких случаях зависит от опыта. Новичок и в трёх файлах запутаться может.

В принципе, если нет желания тянуть в проект Qt только ради сигналов и слотов, то можете попробовать использовать Boost.Signals2. Но только в том случае, если это новый проект. Не стоит в старом проекте дружить сигналы и слоты этих двух библиотек.

Какие-либо остальные библиотеки сигналов и слотов я бы вообще не рассматривал.

За использование Qt могу ещё сказать, что в embedded проекте можно использовать сетевые части Qt, то есть тот же самый QNetworkAccessManager , который является очень удобной штукой и позволяет значительно быстрее написать обращение к сайтам, серверам и т.д. чем какие-либо други библиотеки, а также имеет весьма удобную поддержу json. Я пробовал работать с json на другой библиотеке, по личным ощущениям было не так удобно. Также есть парсинг XML и т.д.

В общем не стоит сбрасывать со счетов Qt, если на первый взгляд он вам нужен только для сигналов и слотов. Там есть ещё много плюшек, которые весьма неплохо реализованы.

Cпасибо. Да, проект многопоточный и он должен уметь собираться под разное железо.
Т.е. надо под каждую отличающуюся платформу пересобирать qt. Вот эт прям бесит.

Ну в каждой избушке свои погремушки, поэтому нет гарантий, что не придётся пересобирать boost, частично он конечно шаблонный, но есть и часть функционала, который компилируют.
Многопоточность можно также решить и потоками boost или std, но если честно, тот же самый QtConcurrent весьма классная вещь, когда нужно распараллелить какие-нибудь вычисления, и собрать потом результат в одну кучу. Весьма удобно для локального распареллеливания какой-нибудь математики, когда дошли до какого-то места программы и не нужно проходить дальше, пока вычисления не будут готовы. А QtConcurrent с блокировкой выполнения позволяет раскидать математику по всем имеющимся ресурсам, пока не выполнит вычисления, а потом обратно в один поток собирается.

Json в Qt реализован не лучшим образом. Если важна скорость обработки тех же реквестов, то рекомендую использовать RapidJSON. Данную библиотеку очень просто интегрировать в проект, нужно просто скачать ее и прописать INCLUDEPATH в файле сборки проекта. Ниже привожу общий рейтинг json-библиотек, а также их рейтинг по различным параметрам (parsing time, parsing memory, stringify time, prettify time, code size).