[SapFossil]

Zunehmend verwenden Entwickler (oder per "Order-di-Mufti") ABAP/OO für betriebswirtschaftliche Funktionen in klassischen SAP-Reports.
Das geht!
Da werden dann zig lokale Klassen und (auf deutsch) für jeden popeligen "MOVE" Methoden angelegt.
Bei START-OF-SELECTION geht's es dann auch gleich mit CREATE OBJECT xyz und CALL METHOD xyz->MAIN() zur Sache.
Dann jagt da eine Methode die andere und alles nur, um ein paar Daten zu selektieren, zu verdichten und diese schließlich auszugeben.
Diese Funktionalität erkennt man aber erst dann, wenn man sich mangels Dokumentation mühselig mit dem Coding auseinandergesetzt hat.
Sorry, diesen Menschen sollte man sofort den Zugang verwehren.
Sie haben Sinn und Zweck von Modellen, Klassen und Methoden nicht verstanden und es erscheint als Versuch, sich damit allmählich einen Erbhof aufzubauen.

Window-Anwendungen wie auch WEB-Entwicklungen wären ohne OO-Werkzeuge nicht denkbar.

Aber braucht man all das auch bei betriebswirtschaftlichen SAP-Anwendungen?

Die kompletten SAP-Applikationen sind ein Meisterwerk langjährig entwickelter prozeduraler Module, die im weitesten Sinn besser als Prozessoren zu bezeichnen und die aufgrund ihrer unvergleichbaren Tabellensteuerung über tausende von Einstellungen flexibel steuerbar sind.
Allein der Umgang mit diesen Einstellungen erfordert ein hohes Maß an Fachwissen und Erfahrung.
Dafür gibt es dann den Begriff des Customizing.
Customizing, das gibt es mittlerweile sogar im eigenen modernen KFZ. Professionelle Command-Systeme erlauben z. B. dabei einzustellen, ob das Verriegeln mit Blinkzeichen quittiert oder die Spiegel beim Verlassen eingefahren werden sollen. Projizierte man die Menge der SAP-Einstellungsmöglichkeiten auf das Auto: man würde wahrscheinlich erst nach Monaten das Fahrzeug besteigen können. Über den Flug zum Mond sollte man erst gar nicht nachdenken.
Aber ohne diese Technik wären die vielseitige Branchenverwendbarkeit, der damit verbundene reduzierte Pflegeaufwand seitens des Herstellers und schließlich die Erfolgsgeschichte von SAP nicht denkbar gewesen.
Reichten zu Zeiten des SAP R/2 und auch in den ersten Releases des SAP R/3 noch Funktionsbausteine zur Ausführung gleichartiger Anforderungen, so haben u.a. Fenstertechnik, Zugriff auf Office-Anwendungen und Anbindung von WEB-Applikationen (WEB-Dynpro) eine Ausweitung des ABAP4-Sprachumfangs auf objektorientierte Sprachelemente erforderlich gemacht. Sinnvolle Verwendungen dieser entwickelten OO-Technik findet man im prozeduralen SAP-Gesamtwerk z.B. als alternative Erweiterungsmöglichkeit über BADIs (Enhancements) oder bei der genialen GRID-Technik (ALV).
In Summe also Stellen, die eine Wiederverwendbarkeit in unterschiedlichen Kontexten erfordern und technische Finessen, die das Mega-System an markanten Punkten zielorientiert moderner und damit effektiver und transparenter machen.
Weniger sinnvolle Anwendungen (Meinung des Autors!) findet man z.B. in den enjoy-Transaktionen, die sich nicht nur damit von der bekannten und bewährten SAP-Philosophie abgewendet haben. Nicht unerwähnt bleiben soll auch die Verarbeitung von Langtexten, die zwar optisch einen modernen Eindruck hinterlässt, hintergründig aber nur einen winzigen Bruchteil der Komplexität von bekannten Officeprodukten verwendbar macht.
Schließlich erinnert der erfasste Text in seiner internen Aufbereitung doch wieder nur an EDLIN-Zeiten und stellt den Entwickler bei häufig verwendenten "CALL TRANSACTION"-Szenarien wie z.B. bei den Transaktionen VA01/VA02 vor enorme Probleme bzw. zwingt zur Verwendung von BAPIs, die in aller Regel nicht die gleiche Flexibilität aufweisen.
Die klassischen betriebswirtschaftlichen Applikation erfreuen sich weiterhin prozeduraler Techniken und sind auch für Entwicklungs-Laien (Anwender) inhaltlich zumindest verständlich ("übersetzbar"). Wie es sich dann zur Laufzeit verhält, lässt sich oft aufgrund nicht erkennbarer Tabellenwerte nur mit dem Debugger erkennen.
Dabei gibt es (anspruchsvolle!) SAP-Funktionsbausteine, die noch heute die klassische interne Tabelle mit Kopfzeile - sogar mit gefüllter Kopfzeile! - erwarten (z. B. Funktion: GET_STPO). Alles andere liefert kein erwartetes Ergebnis.
Ist die erweiterte Programmprüfung oder gar der Code-Inspector vom Auftraggeber gefordert, so ist der Aufwand, die in diesem Zusammenhang aufgezeigten Fehler mit #-Anweisungen zu versehen, größer als der für die Anwendung darselbst.

Mit ABAP/OO sieht das im betriebswirtschaftlichen Umfeld leider anders aus.
Man muss zunächst das Modell verstehen - sofern es eins gibt und eine Beschreibung existiert -, um Sinnhaftigkeit und Zweck zu erkennen.
In der Regel gibt es in konstruktiven Eigenentwicklungen zur Erweiterung fehlender oder andersartiger betriebswirtschaftlicher Abläufe technisch selten Wiederverwendbarkeitsanforderungen. Aufwendig angelegte lokale Klassen mit implementierten Methodenwerk in sogenannten gekapselten Einmal-Reports haben dann einen Nährwert von Null.
Wenn man in diesen Zusammenhang dann noch von Vererbung spricht, bleibt begrifflich wenigstens das Erbe für den Nachfolger, wenn der Entwickler das Unternehmen wechselt.

Fazit:
Wenn eine Entwicklung oder auch Teile davon den Anspruch auf Wiederverwendbarkeit erscheinen lassen, unterschiedlicher Kontext innerhalb einer Anwendung erforderlich ist, transparente Unterprogramme bzw. Funktionsbausteine dieses nicht mehr leisten können, dann sollte man sich ein OO-Modell überlegen, welches auch zukünftigen Erweiterungen standhält, also eine Erweiterung ohne ständige Überarbeitung zu Lasten von Verwendern erlaubt.

Das sollte jedem klar sein.

Alles andere ist doch die Sackkarre mit NAVI und Bluetooth. Das wär's doch!

[jesizme4abap]

Oberfächlich betrachtet scheinen viele deiner Argumente zu stimmen. Was deine Beobachtungen angeht, in welcher Weise sich einige "OO-Spezialisten" dieser fortschrittlichen Programmiertechnik bedienen, muss ich dir leider beipflichten.
Dennoch - Richtig angewendet, macht OO den Code robuster und die Anpassung an stetig sich verändernde Anforderungen (ja, die gibt es auch im betriebswirtschaftlichen Umfeld reichlich) einfacher.
Und oft genug verwende ich Klassen wieder, die ich dereinst für eine einmalige Verwendung geschrieben habe.
Entwicklungen in OO-ABAP sind (ebenso wie in Classic ABAP) auch nur so gut, wie ihr Design(er).
Wenn man verstanden hat, dass OO nicht eine andere Art zu programmieren, sondern eine andere Art zu denken ist; wenn man sich an einige wichtige Grundregeln hält UND bereit ist, stets und ständig dazu zu lernen - dann (und nur dann) entfaltet OO seine heilsame Wirkung.
Im übrigen halte ich (fast)nichts von lokalen Klassen, die sich in irgendwelchen obskuren Includes herumdrücken und das Licht der Öffentlichkeit (meist nicht ohne Grund) scheuen. Ich baue meine Klassen global.
Welches Problem hast du mit der Vererbung? Fehlt dir die multiple inheritance?
Ich finde die einfache vererbung in Verbindung mit Interfaces meist völlig ausreichend.
Mal ehrlich, wer einige Jahre im Geschäft ist (und dem Klang deiner Worte nach bist du auch nicht erst seit letztem Jahr dabei)
hat oft genug das Erlebnis: "Das habe ich doch erst letztes Jahr für xyz gebaut, ein paar kleine Änderungen hier und da - Strg c - Strg v
und voilà fertig ist das Progrämmchen."
Genau da trennt sich die Spreu vom Weizen.
Ich verwende meine Klassen "as is" oder wenn nötig, eine Erbklasse davon. Und dann mache ich meine Änderungen, so sie denn überhaupt notwendig sind, in der Erbklasse.
Erstmal gibt es ein ordentliches Interface. Das ist in der Regel das einzige, was Berührung mit den ausführenden Programmen hat.
Dann gibt es eine abstrakte Klasse. Darin ist sämtlicher Code enthalten, der stets gleich bleibt. Den Rest, d. h. das was sich gerne und häufig ändert, übernehmen die Nachkommen. Und die machen das, wie es sich gehört, im Verborgenen. Meine Programme merken davon nichts.

Ach ja, das Customizing.
Wer sagt denn, dass man mit OO nicht ebenso gut, ja teilweise sogar besser, mit Customizing Tabellen arbeiten kann?
Ein paar Klassen, die das gesamte Customizing vorrätig halten, sind ja wirklich kein Hexenwerk.
Und dann so schöne Dinge, die man mit dem BFR+ anstellen kann. So richtig schön komplizierte Entscheidungen, für die ich mir im ABAP die Finger brechen müsste (jedenfalls wenn ich die Logik denn auch noch gekapselt habe will) lagere ich einfach aus und lasse mir das Ergebis vom BFR+ zurückliefern.
In enem Punkt gebe ich dir Recht. Bei der zeitkritischen Massenverarbeitung von Daten (Jahreabschluss etc.), bei der Tonnenweise Bits&Bytes verschoben werden, wo ich ein (mehr oder weniger) ausgereiftes Framework von vorhandenen Funktionalitäten zur Verfügung habe, werde ich mich hüten, die Perfomance mit Objekten zu stören. Andereseits werde ich mich i. d. R. auch hüten, die Performance mit FuBas oder selbst gebastelten, am besten noch externen, Performs zu stören. Dann sogar doch noch lieber OO

Es gibt durchaus gute Gründe dafür, warum die SAP allmählich vollständig auf OO wechselt. Ab Basis 7.40 gehören z. B. Performs schon zu den obsoleten ABAP Konstrukten. Die Gründe dafür sind u. a. dass die Typisierung von Parametern optional ist, dass man auch Using Parameter puppenlustig verändern kann, dass die Zuweisung der Parameter ausschließlich über die Reihenfolge geschieht etc.

Und schließlich:
Wer nicht mit Zeit geht - geht mit der Zeit.