1) Принцип инкапсуляции - сокрытия подробностей внутреннего устройства от клиента. Клиент может модифицировать поля только строго определенным образом, через методы, при этом метод может проверить, чтобы изменение значений было осмысленным. Совершенно открытые поля оставляются только у записей, у которых нет поведения, т.е. структур данных, не являющихся полноценными объектами.
В других языках приходится вводить пару методов - Get и Set.
В Обероне можно открыть поле только для чтения, а для изменения ввести методы. Иногда это серьезный плюс к быстродействию.

2) "т.е. у двух объектов одного класса могут быть разные методы? "
Именно так. Как, например, в Дельфи у двух компонентов одного типа TButton могут быть разные обработчики OnClick.

3) Так метод в стиле классического Оберона - это всего лишь процедурное поле, указатель на процедуру. А самой процедуре надо еще раз сообщать, для какого объекта она вызывается.
Т.е. был стиль вызова: object.Do(object, ...).
Не особенно удобно. Поэтому Мессенбеком в Обероне-2 и были введены связанные процедуры. Явный параметр в них остался, но его уже не нужно явно дублировать при вызове.

4) "т.е. когда мы создаем класс мы не указываем какие у него есть методы? "
"Создание класса", т.е. определение класса - это вся совокупность определений в модуле. Т.е. само описание структуры типа данных RECORD и затем - введенные связанные процедуры.
Убрать процедуру - это значит изменить тип. В частности, модули-клиенты сразу потребуют перекомпиляции, несовместимость.

5) Мы определяем ИНТЕРФЕЙС без реализации. А реализовать этот интерфейс предоставляем конкретным типам-расширениям.
Т.е. ABSTRACT-тип - своего рода разъем. Затем мы определим конкретные типы, реализующие эти разъемы и соединим их, при этом они ничего не будут знать о деталях реализации друг друга. Как в IBM PC - по стандартным разъемам можно подключить любую реализацию.
Подробнее в любой книжке по той же Делфи можете почитать, абстрактные классы применяются во всех распространенных ОО-языках.

6) Добавление предку процедуры с именем потомка - это ошибка.
Проектная ошибка. Потому что создатель типа-потомка предполагает, что он впервые ввел такую процедуру. А создатель типа-предка вводит свою, не зная, что такая уже есть. МОжет быть, эти процедуры вообще имеют разное назначение, только одинаковые имена. Такой путаницы допускать нельзя.
На практике, когда мы пишем модуль для широкого использования, единожды определив экспортированный тип, мы вообще не имеем права менять его "фасад", кроме внутренней реализации.

Да, еще, почитайте раздел хелпа Блэкбокса - "Что нового в языке".