В гугле по словам "rabbitmq" и "rpc" выдаётся ссылка на оф.документацию по Direct reply-to, Вы пробовали такой механизм? Создание/удаление очереди ради получения одного ответа это очень накладно. 50/400rpc это вообще не о чём, даже для RabbitMQ (конечно всё зависит от выделенных ресурсов, хранению на диске и т.д.).

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

Из текста не до конца понятно, Вы хотите, чтобы была очередь или sender должен выполняться каждый раз для нового сообщения? Если очередь, то обрабатывать сообщения по одному можно, но только если получатель один. В протоколе AMQP можно вручную получать сообщения по одному - basic_get, или выставить количество неподтвержденных сообщений в 1 и подтверждать обработку каждого.

С серверной стороны используется всего 1 порт, это клиентская часть выбирает случайный (по умолчанию), так что количество клиентов, которое может обслужить сервер RabbitMQ (да и любой другой сервис) не ограничено лимитом портов. (Например, в Linux каждое соединение характерирузется 5 параметрами {proto, src_ip, scr_port, dst_ip, dst_port}.)

Ограничение дают вычислительные ресурсы, которыми распоряжается RabbitMQ. Так как очереди в RMQ не самые простые, то они потребляют достаточно памяти, я бы сказал, что каждая очередь (при условии что там немного сообщений) потребляет 30-50 КБ RAM. Можно попробовать включить режим Lazy Queue, чтобы RQM всегда писал/читал с диска и не кэшировал сообщения в памяти. Также RMQ любит процессор, но может хорошо распределить нагрузку между всеми ядрами.

В кластерном режиме RabbitMQ может распределить очереди по всем серверам и обслуживать клиента на любом из них (но балансить клиентов также надо по всем узлам, в идеальности "привязать" клиента к одному серверу). Но проблемы начнутся, когда узлы RMQ начнут "падать" :-) Плюс метадата об очередях синхронизируется между всеми серверами, так что, если поток команд на создание/удаление очередей будет высок, то только на этом может съесться куча процессора и сети.