Зачем придумали классы если в структурах есть все тоже самое что и в классах, только по умолчанию объекты public.

Ну если спрашивает то видно ему слово поли да какой-то морфизм не известно.
А Руслан правильно говорит и многое еще не договорил :)

Одно слово: полиморфизм.

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

Для того чтобы можно было иметь поля private и protected, множественно наследовать, перегружать и полиморфить )

А вообще на самом деле ООП-код просто более нагляден и лучше поддается доработке

Структуры используют большую часть того же синтаксиса, что и классы, однако они более ограничены по сравнению с ними.
В объявлении структуры поля не могут быть инициализированы до тех пор, пока они будут объявлены как постоянные или статические.
Структура не может объявлять используемый по умолчанию конструктор (конструктор без параметров) или деструктор.
Структуры копируются при присваивании. При присваивании структуры к новой переменной выполняется копирование всех данных, а любое изменение новой копии не влияет на данные в исходной копии. Это важно помнить при работе с коллекциями типов значений, такими как Dictionary<string, myStruct>.
Структуры являются значимыми типами, а классы — ссылочными типами.
В отличие от классов, структуры можно создавать без использования оператора new.
Структуры могут объявлять конструкторы, имеющие параметры.

а как же методы?

"Тот факт, что и структуры, и классы обладают практически идентичными возможностями, создает впечатление избыточности. Многие новички в программировании на C++ недоумевают, почему в нем существует такое очевидное дублирование. Нередко приходится слышать предложения отказаться от ненужного ключевого слова (class или
struct) и оставить только одно из них.
Ответ на эту цепь рассуждений лежит в происхождении языка C++ от С и намерении сохранить C++ совместимым снизу вверх с С. В соответствии с современным определением
C++ стандартная С-структура одновременно является совершенно законной С++-структурой.
В языке С, который не содержит ключевых слов public или private, все члены структуры являются открытыми. Вот почему и члены С++-структур по умолчанию являются открытыми (а не закрытыми). Поскольку конструкция типа class специально разработана для поддержки инкапсуляции, есть определенный смысл в том, чтобы по умолчанию ее члены были закрытыми. Следовательно, чтобы избежать несовместимости с языком С в этом вопросе, аспекты доступа, действующие по умолчанию, менять было нельзя, поэтому и решено было добавить новое ключевое слово. Но в перспективе можно говорить о более веской причине для отделения структур от классов. Поскольку тип class синтаксически отделен от типа struct, определение класса вполне открыто для эволюционных изменений,
которые синтаксически могут оказаться несовместимыми с С-подобными структурами.
Поскольку мы имеем дело с двумя отдельными типами, будущее направление развития языка
C++ не обременяется
"моральными
обязательствами", связанными с
совместимостью с С-структурами.

Под "занавес" этой темы отметим следующее. Структура определяет тип класса.
Следовательно, структура является классом. На этом настаивал создатель языка C++, Бьерн
Страуструп. Он полагал, что если структура и классы будут более или менее эквивалентны,
то переход от С к C++ станет проще. И история доказала его правоту!" (с) Г. Шилдт

По правде говоря, вполне можно обойтись и без них.
ООП - не единственная парадигма, и свет клином на ней не сошелся.

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

Что получается при использовании не-ООП-языка без этого условия, мы видим на примере Си под ВинАПИ. Код хеллоуворлда, написанный одним человеком, может в корне отличаться от такого же кода хеллоуворлда, написанного другим.