Вопрос о событии PropertyChanged интерфейса INotifyPropertyChanged.
Допустим инвокер - метод OnPropertyChanged(string propertyName);

Вижу два варианта логики вызова:
1. Вызывать только тогда, когда значение свойства действительно изменилось (строгий вариант).
2. Вызывать когда оно возможно изменилось (нестрогий вариант).

Собственно вопрос - какая из двух практик более "по феншую", больше соответствует MVVM. 
А также - приемлем ли нестрогий вариант вообще и в каких случаях. 

Почему задаю такой вопрос - потому, что нестрогий вариант проще в использовании и поддержки со стороны класса, вызывающего событие.
Однако строгий вариант - более "честный" и исключает вероятность ошибки на стороне клиента, вызванной неверным предположением, что свойство действительно изменилось (а оно могло остаться прежним).

если я правильно понял вопрос - то в сеттере привязанного свойства сначало идет проверка на равенство с уже имеющимся значением. если равно то ретурн, если нет то PropertyChanged

В простейшем случае да, но это возможно когда мы точно знаем, что значение изменилось и непосредственно меняем свойство.
Но иногда бывает, что у свойства, например, нет сеттера, а гет делегируется куда-нибудь дальше.

Мне кажется, тут всё зависит от ситуации. Универсального рецепта нет.

Мне кажется это не то место, где можно настолько просесть по перфомансу, что бы размышлять "вызвать или не вызвать"...
Я всегда пишу вызов в сеттере без проверок:

чувак говорит не о том, а о том что у него еще есть свойство B:

и мол ты A меняешь, надо ли вызывать PropertyChanged("B") ?

Я считаю что надо. Если класс реализует INPC то все его свойства должны обеспечивать интерфейс.
Вопрос усложняется когда B зависит не от одного свойства A, а от нескольких.. тут надо крутить что-то вроде BeginUpdate()--EndUpdate() чтобы не дергать "B поменялся" впустую.