Как лучше писать if условия?

Лучше писать так:
return (foo == bar && foo >= 1) ? true : false;

Второе лучше, потому как в первом { можно { получить { миллиард { уровней { вложенности } } } } }

1. Согласен с тем что выходить нужно как можно быстрее. Поэтому лучше как-то так:

if(foo != bar || foo < 1) {
  return false;
}
// логика
return true;

2. Деление условий должно быть осмысленно с точки зрения бизнес-логики. Если условие foo != bar || foo < 1 является целостным и неделимым с точки зрения бизнес логики, то лучше его не делить.

Если же это 2 разных условия (две разных ситуции), просто скомпонованных в одно условие, то вполне допустимо их разделить для логического выделения (опять таки с точки зрения бизнес-логики). Например, если foo - кол-во товаров в заказе, a bar - кол-во товаров при котором дается скидка (не больше не меньше):

// кол-во товара в корзине != кол-ву товара при котором делается скидка 
if(foo != bar){
    return false;
}

// если корзина вообще пуста
if(foo < 1){
  return false
}

// применение скидки к заказу

return true;

Если допустим, то обоими, и плюс еще несколькими.

Вариант 1 конечно. Читаемость прежде всего. По производительности по моему тоже если первая проверка не пройдет второй уже не будет проверятся.

if (!(foo == bar && foo >= 1)) return false;

подход называется "ранний выход", и призван он улучшить читабельность.

Вы должны завершить работу функции так рано, как это возможно. Дальше может быть создание больших и сложных объектов, а потом фигак и параметр null, а вы уже насоздавали всего ненужного.

Можно ещё используя Short-circuit evaluation:

res = true
res &&= (foo == bar)
res &&= (foo != baz)
if (res) some_logic1
res &&= (foo >= 1)
if (res) some_logic2
return res

Преимущество кода в том, что проверки идут друг за другом, линейно, а не вложенно.
В отличие от, скажем, такого кода:

res = false
if (foo == bar && foo != baz) {
  some_logic1
  if (foo >= 1) {
    some_logic2;
    res = true
  }
}
return res

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

Вариант 1, конечно! Во втором даже ; нет

Лучше не писать return в условии вообще, один return в конце функции.
А условия объединять стоит если они логически объединены общим смыслом. Т..е. их потенциально можно вынести в отдельную функцию.
Написано только что

Сперва лучше писать "нормальное" прохождение условия (т.е. то, когда алгоритм идёт по "ожидаемому/приемлемому" сценарию). А потом уже делать ответвления на "отклонения от нормы".
Конечно же, данный совет не всегда применим :)

Лучше с чьей точки зрения?
Если человека, то Вам тут уже много понаписали.
Я программирую контроллеры, там другой подход и другое понимание "лучше" - в сомнительных случаях пишу несколько вариантов и смотрю ассемблерный код. Именно его (так себе это можно представить, несколько упрощая реальность) и будет выполнять CPU.
Да, есть еще и точка зрения оптимизирующего компилятора. Его точка зрения как раз и выражается в ассемблерном коде.
Как правило, "скучный и плоский" лучше оптимизируется - keep it simple, stupid. :)