Потому что "так писать быстрее и так весь код в исходниках" . С какой-то версии, правда, для глобальных классов появилась кнопка "Source Code- Based". Но там названия переменных несколько отличаются от отображаемых, плюс se24 немножко форматирует код (добавляются комментарии с информацией о параметрах, комментарии перед методом вносятся внутрь).
+ все на виду
+ проще откатывать изменения, массово что-то менять, рефакторить
+ проще переносить код между системами (скопировал - вставил)
+ удобнее работать с исключениями (в se24 конструктор для них генерится)
+ при переносе глобального класса программы, его использующие и работающие в это время, начинают резко перегенерироваться, что совершенно не радует пользователей
Да и не люблю я САПовские конструкторы, и словарь предпочитаю использовать только при острой необходимости.
Как Вам покажется удобным. Я в отдельные [библиотечные] инклуды запихиваю логически связанный [между собой], но независимый от конкретных программ код. Это может быть как отдельный класс, так и интерфейс и иерархия классов, или даже классы разных иерархий, которые работают вместе. Если возникает зависимость от кода из другого инклуда, этот инклуд просто подключается к текущему. Главное - не доподключаться до взаимных зависимостей .
Глобальные классы неудобно править. Обычно приходится изменять сразу несколько методов или перемещать компоненты класса между секциями или по дереву наследования. Соответственно, приходится постоянно куда-то заходить-выходить, открывать в соседних сессиях и т.д. А если еще и посреди дороги передумал... В общем, править локальные гораздо проще.

Не надо. Но зато быстро и удобно .

Если возникает потребность повторного использования локального класса, то для этого в SE24 есть импорт локальных классов. Пара кликов и он теперь глобальный.

Лично я на текущий момент использую такой вариант: некая "рыба", отдаленно напоминающая MVC, реализованная глобальными интерфейсами и классами. Если оно подходит под задачу - локальное наследование, переопределение пары методов (например, для селекта).

Не хватает только ооп реализации экранов И перегрузки методов

Конечно же кроме человеческого фактора ничем не грозит, тут всё как и с обычными инклюдами. Просто в таком случае не понятно почему именно локальный класс, а не глобальный. Если в случае стандартных форм другого выбора для реюза кода нет(ФМники всё же немного не то, ), то в случае с классами, если требуется использовать один класс в нескольких разработках - лучше сделать глобальный класс.

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

Локальные классы другой программы кстати тоже можно вызывать не делая импорта

И множественного наследования.
И, при наличии переопределенного метода, возможности вызывать не только родительский метод (super->...), но "дедовский" метод (т.е. метод не прямого предка, а более далекого).
И, при наличии переопределенного метода, возможности вызывать родительский метод (super->...) не только из переопределенного, но и из других методов.
И применения двух(много?)проходности для локальных классов.
И возможности самостоятельно создавать конструктор для глобальных классов исключений.
И лучше бы вместо мутного cleanup сделали явовский finally.
И ООП-гуи-статусов, до кучи. Хотя и никогда не требовалось.

Если для реализации вашего решения всё это требуется, то это выходит несколько за границы озвученного вопрос "1 программа где-то на 5000 строк" В обычной программе такая таксономия классов, где всё это будет иметь смысл - нафиг не нужна.
А множественное наследование вообще зло, лучше уж интерфейсы + миксины.

Пару дней подумал и понял что это значит.
Наверное, действительно лучше не подключать инклюд1 внутри другого инклюда2.
А подключать инклюд1 туда, куда подключается инклюд2 (в программу с селекционным экраном). Все прекрасно будет компилироваться. Ведь отдельно инклюд не компилируется, система просит указать головную программу.

Вы кажется только что изобрели dependancy hell

Бывают задачи настолько навороченные, что аж зла не хватает .
Под миксинами (или примесями - https://learn.javascript.ru/mixins) подразумеваются вспомогательные классы (ака хелперы, ассистенты и т.д.), которые не входят в основную иерархию?

Тогда придется помнить, какой инклюд от каких зависит. При создании новой программы это не особо страшно - компилятор подскажет. А вот если уже есть десяток-два-и-больше программ, использующих инклюд-1, и тут ВНЕЗАПНО применение инклюда-1 становится возможным только вместе с инклюдом-2? Тем более, не на всех проектах приветствуются правки программ, формально не имеющих отношения к решаемой задаче.