Семантические конфликты не являются специфичными исключительно для бранчинга и будут везде, где более одного разработчика работает над одним и тем же набором файлов. И например DVCS (Git, Mercurial, etc) хранят полную историю коммитов (в отличие от многих централизованных систем), что облегает процесс мержа.
По пунктам 1 и 2 упомянут механический и интеллектуальный overhead при использовании веток. Каждая новая ветка не бесплатна и добавляет сложность в процесс. Ветки позволяют обойти ограничение реального мира на то, что трудно одновременно стабилизировать и разрабатывать. Тем не менее количество веток должно быть сведено к необходимому минимуму именно по причинам накладных расходов на их поддержку.
По пункту 3 я не считаю что ветки являются препятствием для CI, это упомянуто. Впринципе для того чтобы собирать нужную ревизию необходимо просто обновить рабочую копию, на которой собирается билд на нее, все остальное одинаково для всех веток. Грамотный билд инжиниринг поможет решить этот вопрос. Насколько просто это реализовать зависит от используемой инфрастурктуры.
Это не основано на Continuous Delivery, скоре на материалах по разным VCS и по СI. Итеративный процессе в agile команде будет основан на CI / использовании бранчей / автоматическом тестировании / автоматическом развертывании, так что сам принцип Continuous Delivery не несет в себе ничего нового.
Статья про основы использования бранчинга. Целью было описать базовое применение и познакомить с overhead'ом/зависимостями при активном использовании веток. Естественно, использовать нужно только то, что работает и вариантов эффективно применять ветвление намного больше.
По пункту 3 я не считаю что ветки являются препятствием для CI, это упомянуто. Впринципе для того чтобы собирать нужную ревизию необходимо просто обновить рабочую копию, на которой собирается билд на нее, все остальное одинаково для всех веток. Грамотный билд инжиниринг поможет решить этот вопрос. Насколько просто это реализовать зависит от используемой инфрастурктуры.