Какие минусы могут вылезти в дальнейшем при такой примитивной реализации очереди задач?
При такой реализации проблемы вылезут сразу, как только случится несколько одновременных запросов к вашей службе из-за отсутствия синхронизации потоков, если только вы не используете Single режим для службы. Но тогда непонятны заморочки c Parallel.ForEach и прочие очереди. 
1. в addCall несколько потоков могут попытаться добавить один и тот же ключ в словарь calls и это будет exception
2. в invokeAll перед выходом очищается словарь calls, при этом на момент выходы из этого метода в нем вполне могут оказаться новые команды, которые будут также удалены
3. Wait() перед выходом из AddDataToDevice заблокирует поток, который будет ждать окончания выполнения другого потока, который был запущен в  Parallel.ForEach - странно выглядит
4. В методе getInfo не обрабатывается ситуация отсутствия ключа в словаре, в таком случае будет выброшено исключение 
5. перед вызовом invokeAll не проверяется был ли завершен предыдущий вызов. Если первый вызов invokeAll не успел завершиться за минуту и придет второй, то тут вообще начнется каша от исключений при переборе ключей словаря, до отправки одних и тех же команд несколько раз
6. Данные из словаря callsInfo не удаляются, что при длительной работе приведет к утечкам со всеми вытекающими 
Но если вы используете Single mode для WCF service-а, либо в один момент времени может быть только один запрос на сервис, то наверное будет работать.
Ну послушайте - это же зависит от конкретной нагрузки.
Количества клиентов и скорости обработки одной команды (и стабильности скорости этой обработки, то есть real-time есть или нет).
Если не так все требовательно (как вы и описали), то я бы ориентировался на удобство и понятность и простату для разработчика.