Насколько реально нужен консул девопсу?
Никто не заставляет использовать docker, systemd, ansible и вообще какие угодно системы оркестрации и оптимизации. Необязательно делать шаблоны конфигов или кластерные конфигурации сервисов, необязательно использовать библиотеки настраиваемого логгирования, возиться с балансерами и реприцируемыми базами. Но люди это делают, значит, смысл всё-таки есть?

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

Консул - это тоже инструмент. Вряд ли хоть кто-то использует его возможности целиком и полностью, тем более что никто не заставляет. Кому-то достаточно того, что у него все сервисы зарегистрированы в одном месте и из коробки имеют автоматическое DNS-имя вида NAME.service.consul. Кто-то использует kv-хранилище для хранения параметров, а кто-то хранит в нём секреты и целые конфиги, настраивает токены с различными acl и скрещивает всё это с consul-template. Вообще, необязательно использовать именно консул, есть и другие инструменты для подобных задач. Например, zk/etcd.

Консул чаще используют совсем не с ансиблом, а с инструментами оркестрации, в которых сервисы могут расширяться и сворачиваться, перезагружаться и мигрировать. Скажем, пусть у нас есть условный сервис rabbitmq на три ноды. Тогда у нас может быть три контейнера rabbitm{1..3}, при запуске они регистрируются в консуле скриптом запуска вместе с проверками, а далее consul отдаёт их все три в виде имени rabbitmq.service.consul. Если какой-то из них вдруг упадёт, consul оперативно это обнаружит и исключит из DNS проблемный узел. Если вдруг управляющий всем этим администратор или автоматическая система оркестрации посчитает нужным добавить новые узлы или перенести их куда-то ещё в кластере, то consul также отразит все нужные изменения. При этом использующее rabbitmq приложение должно будет знать только адрес rabbitmq.

Конечно, любую задачу можно обвесить скриптами, костылями и даже самописными плейбуками без использования готовых инструментов, а потом повторно решать десятки задач, которые уже сто раз решены до тебя опытными людьми, но зачем?
Потому что вы сами можете забыть добавить
Например новый сервис или сервер его надо добавить в том места
А вы взяли и не добавили