Как влияет форматирование кода на гит конфликты?

это скорее связано не столько с конфликтами гита, как с одним стилем кода на проекте. Каждому разработчику нравится писать код в определенном стиле. Представьте себе, какой ужас будет твориться в файлах, когда команда из 10 разработчиков будет писать код каждый в разном стиле. А если на проекте сотни или тысячи разработчиков?
Это будет ппц. И вот мне пару дней назад достался такой проект на доработку. Единого стиля нет. Кто как хотел так и писал. Поэтому и придумали какие-то стандарты написания кода.

Почему в командах , которая занимается разработкой с использованием git , есть определенные правила настройки редактора кода ?

Никогда раньше не слышал, что это связано именно с использованием Git.

Думаю, к конфликтам это никак не относится (напрямую), просто табуляции в разных редакторах выглядят по разному и не редко "4 пробела" и "Таб" - это не одно и то же, даже визуально. Например, в редакторе VI(M) по умолчанию, "Таб" выглядит скорее как 8 пробелов, нежели как 4.

А ещё некоторые языки могут быть зависимы от отступов, Python например, и разные варианты отступов могут давать неожиданное поведение в некоторых случаях...

Вообще, обычно принято использовать "4 пробела" вместо Tab'а... многие редакторы умеют заменять "Таб" на "4 пробела"...

Ну и когда все пишут "в едином стиле", потенциальное количество проблем, в т.ч. в будущем, например при анализе исходного кода машинным способом - значительно сокращается.

Никак.
Данное требование не относится к гиту, но относится к внутренним стандартам по оформлению кода.

На самом деле есть в этом пару моментов важных для работы в git, да и не только

Попробую рассказать на примере:
Есть у нас функцию вида

function parseData({options = {}, lang, info, test, data, ...other}) {
}

Далее в нее 2 разработчика делают изменения
1)

function parseData({options = {}, lang, info, test, data, data2, ...other}) {
}

2)

function parseData({options = {}, lang, info, test, data, info, ...other}) {
}

у нас будут конфликты, в случае форматирования такого, проблем будет меньше

function parseData({
  options = {},
  lang,
  info,
  test,
  data,
   ...other,
}) {
}

так же еще один момент, чем меньше строк кода мы поправим тем лучше отсюда к примеру запятая в конце объекта это хорошая штука:

const data = {
  attr1: '',
  attr2: ",
}