basrach

1. Regex.Replace(@"https:\/\/pp.userapi.com\/c841226\/v841226735\/72c15\/CrqCyt7DhCA.jpg", @"\\", "")
2. HTML в общем случае невозможно описать регуляркой. Т.е. такая регулярка возможно будет косячить где-то, но в каких-то простых случаях отработает:

var htmlString = ...
var withoutTags = Regex.Replace(htmlString, @"<.*?>", ""); // удаляем теги
var withoutSpaces = Regex.Replace(withoutTags, @"\s+", " "); // удаляем пробелы

Зависит полностью от вашей задачи. Вот сделали вы там что-то. Если это вас устраивает полностью, всё работает как надо, "они делают всё что необходимо" то значит и контроллеры и прочее - отличные. Может статься, что проект будет расти и усложняться. Когда дефолтные контроллеры + EF без дополнительных слоев абстракции перестанут "делать всё необходимое", а наоборот начнут только усложнять вам жизнь. Тогда вы сами поймете насколько и чем они плохи. До тех же пор, абсолютно ничего плохого в них нет.

Можно. Реализовать фабрику, которая будет лениво вытаскивать identity из контекста, и эту фабрику резолвить в конструкторе сервиса. Делать это нужно именно лениво потому как инстанс службы создаётся до авторизации, а вызов метода службы происходит после успешной авторизации, соответственно на момент создания инстанса службы в контексте будет анонимус либо ничего, но зато там определенно будет что-то на момент вызова метода. Поэтому дергаем фабрику на вызове метода и получаем значение из контекста.

При такой реализации проблемы вылезут сразу, как только случится несколько одновременных запросов к вашей службе из-за отсутствия синхронизации потоков, если только вы не используете 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-а, либо в один момент времени может быть только один запрос на сервис, то наверное будет работать.