Очень жалко, что я не успел во время к этой (и более ранней аналогичной теме ) теме.   
Очень понравилось сравнение себя как класса, стоящего в супермарке в очереди к кассиру:
Не дело это - самому кассиру залазит в мой кошелек и вычитать из того, что он там нашел    сумму за покупки (что-то типа SetCash(GetCash()-5$)).
Он просто должен сказать: "С вас столько-то!" (object.Pay(X dollars))
2-ой вариант, действительно, отражает характер ООП.

А вдруг у меня денег не хватит, тогда (во 2-ом случае, когда данные не выствленны наружу) я могу ну, например, делегировать оплату стоящему с зади меня другу с большим кошельком    или еще что придумать.
Пофантазируем еще, во мне, как в классе, а точнее в моем кошелке, появляется новое поле - КРЕДИТКА! (не являющейся наличкой как бы)

Что мы делаем в 1-ом случае? Правильно, вводим гетеры/сеттеры для нового поля. А кассир что? Правильно. Теперь он лезет ко мне в карман считает деньги, принимает решение, что денег не хватает, смотрит что есть кридитка и т.д. (В прочем, вариант с делегированием другу опять может остаться в стороне)

А во 2-ом случае? Да н_и_ч_е_г_о. Данные скрыты(Свойств, если вам так удобнее, нет). Это мое внутреннее дело, как я буду оплачивать  

Конечно, можно сказать, что это пример надуманного ООП, и геттеры/сеттеры здесь притянуты за уши (гм, разве?), но лучше  я посоветую прочитать ответ на поставленный здесь вопрос, почему get/set не есть хорошо в книжке (C++ Gotchas: Avoiding Common Problems in Coding and Design by Stephen C. Dewhurst ) Она представляет из себя сборник из 100 наиболее распространненых ловушек, куда попадают программисты на с++ (по моему Gotcha N67, но могу и ошибаться).
Не буду гнуть пальцы и кричать, как? вы не знаете кто такой Дьюхарст.. Просто советую. Тем более, что эта книга уже переведена на русский язык...

Предлагаю посмотреть с другой стороны.
С++ нужен для работы программерского коллектива. Отсюда и большинство требований. Так что не парьтесь. Есть дядька, который будет вам расписывать задание на класс. Ваше дело будет выдать ему код в конце рабочего дня. Дальше код пойдет к другому программисту, который не особо будет вникать в вашу начинку. Он воспользуется вашим классом и его методами. Отсюда и требования, чтобы было поменьше дыр, которые дадут вашему коллеге воспользоваться  незадокументированной вами возможностью и чего-то там навернуть лишка в данных.
Сами вы можете писать на чем угодно. На асме или на сях. В одиночку большую программу не поднять, так что вы можете для себя прописывать даже просто структуры вместо классов. С++ конечно облегчил жизнь в "одиночном программировании", но, иной раз вы залазите в конкретную тину, о которой вам даже думать не надо. И мне тоже.
Кстати, С++ тоже не идеал... как показала жизнь. И даже проблема не в наследстве сей. В один момент процесс пухнет. И где там при наследовании классов лишнее сработает не туда.. Рассказать, как я три дня просто у себя искал тупую ошибку в for() и не мог ее увидеть? Просто не верил, что она может быть именно там.

  Ааааа некрофилы, спасайся кто может             

P.S. akizelokro, ИМХО, ты прав, но не надо было разжигать спор опять

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

Тогда ты сам должен понимать, что не всем правилам нужно следовать в 100% случаев. Они, правила, гораздо интереснее своими исключениями. А тогда окажется, что и какой-то get/set будет гораздо более по теме.
А в общем, приведенном в теме смысле, думающие спецы давно бы привели конкретный пример, когда постоянное использование get/set осложнило бы работу при наследовании классов, когда делают дело разные программисты. Эхмы, мой неконкретный опыт мне только подтверждает постоянную сферу действия законов паркинсона и др. и др.
Если полазить раньше по этой теме, то можно было найти вопрос о том, что любой класс нуждается в функции GetOccupied. Это, на мой взгляд, неправильно. Для этого пишется общий предок (либо виртуальный класс, либо класс с виртуальным методом,- четыре года ничего не писал, пошел Страуструпа чтить и искать различия между первоначальным стандартом и практической реализацией стандарта).