Нужна отказоустойчивая система. в Enterprise SQL версии есть очень удобный механизм AlwaysON,Enterprise лицензируеться только Core, 2 ядра стоят 700к руб. соответственно возник вопрос, существует ли метода расчета потребности в ядах SQL сервера? хотя бы примерно?
на резервый конечно по минималке взяли бы на 2 ядра, на основной надо думать

Ядер много не бывает

(1) это понятно, но цены на них кусаются....

например если каждое последующее ядро будет давать выигрыш в скорости на 5% то от него можно отказаться ибо 5% не стоят 350т руб.

(0)
0. В связке с 1С на долю MS SQL приходится относительно небольшое количество отказов. Шансов что неопытный администратор ошибочными действиями положит кластер больше чем шансов что MS SQL ляжет сам или в результате отказов железа.
1. Если нужна только отказоустойчивость и режим активный узел/пассивный узел устраивает, то не обязательно брать Enterprise, Standard поддерживает. Косвенно на то что вам дростаточно Standard слово "резервный" указывает.
2. Лицензируется не меньше 4 ядер на сервер.
И вроде бы не меньше 4 ядер на сокет, то есть если физический сервер и сокетов два то не меньше восьми, но тут я уже не уверен.

(2) Каждое лишнее ядро никакого выигрыша по скорости не даст, это факт.
Оно даст выигрыш по производительности - большее количество юзеров смогут работать.

(3) если я правильно понимаю отличия между стандартом и ентерпрайзе только в том что в ентерпрайзе можно пассивную базу для чтения юзать? не подскажите где про это желательно по шагово почитать можно и как это называется? везде встречаю только примеры с AlwaysON

(5) Нет.
Как я понимаю, Standard поддерживает единственный режим когда работает один узел кластера, при отказе первого узла включается второй, хранилище у них общее.
У Enterprise  много разных хитрых вариантов. Но я не понимаю как всё это великолепие использовать в связке с типовыми конфигурациями 1С на практике. Возможно как-то можно.

(6) хотим без общего хранилища,
с 1с как понял два варианта, или руками сервак прописывать вслучае падения, или через промежуточного слушателя который прописываеться в кластер 1с в качестве SQL сервера который вслучае падения SQl сервака будет переправлять запросы на резервный

Postgres Pro не рассматриваете? там есть очень интересная технология On-line backup (архивирование WAL)