Für Hilfe Anwendungen würde ein reiner (X)HTML Reader genügen. Dafür braucht man weder Javascript, noch Webabssembly, noch Netzwerkcode oder sonstige Features, die in einem Browser alle eingebaut sind.

Eine reine Text und Grafikdarstellung, sowie CSS würde da schon genügen.
XHTML strict würde sich dafür anbieten denn das hält den Parser schlank und einfach.

Das ist natürlich korrekt. Allerdings können JavaScript & co in den meisten Implementierungen zur Laufzeit deaktiviert werden. Also wieso mehr als eine Browser-Engine je System verwenden, wenn es genau eine schon tut? Zugegeben, diese eine Browser-Engine müsste umfangreicher sein, um alle Anwendungsfälle abdecken zu können.

Für Hilfezugriffe ins Web sollte eine GUI Anwendung nicht auf eigene Lösungen setzten, sondern eher den installierten und auf dem System zum Standard gesetzten Browser starten und auf dem die Webseite aufrufen, denn dieser Browser wird auch gewartet.

Dem stimme ich voll und ganz zu. Ich hatte mich jedoch auf lokale Hilfesysteme, die gemeinsam mit einer Anwendung ausgeliefert und verteilt werden, beziehen wollen. Hierfür erscheint es mir in bestimmten Fällen sinnvoller, die Hilfefunktion mittels (genau) einer Browser-Engine-Bibliothek in die jeweilige Software zu integrieren.

Von Umfangreichen Webengines halte ich absolut gar nichts.

Ich bin auch für schlankere Browser-Engines. Problem sind hier im Wesentlichen die auftretenden Inkompatibilitäten der einzelnen Implementierung bzw. der Aufwand diese Inkompatibilitäten aufzulösen. Grund ist die (teils ungerechtfertigte und unnötige) Komplexität, welche hier vorallem aus den historische Altlasten wegen der Abwärtskompatibiltäten, den vielen unterschiedlichen Standards und deren Striktheit/Laxheit, z.B. XHTML(strict) vs HTML5 ("Living-Standard") und ggf. der Ignoranz der Webentwickler_innen, oder die der Implementierer_innen der Browser, herrührt.

Keiner von uns beiden macht die Regeln. Irgendjemand hält es für sinnvoll, umfangreiche Browser-Engines zu entwickeln, obwohl es ein ziemlich aufwändiges Unterfangen ist. Der jeweilige Anwendungszweck begründet die Sinnhaftigkeit.

Die im Toolkit integrierte Lösung verbessert zwar die Situation, ist aber doch nur eine Symptombekämpfung.

Immerhin! Zur Lösung von Problemen zählt im Allgemeinen eben nicht nur die Ursachen-, sondern auch die Symptombekämpfung.

Der Fehler liegt im Design, nämlich, dass man so eine Fullfeatured Webengine erst gar nicht für offline GUI Programme verwendet.

Wieso ist das ein Fehler? Genau eine im Toolkit/System integrierte, umfangreiche Web-Engine, die alle Anwendungsfälle abdeckt, reicht schon. Funktionalitäten, die für einzelne Anwendungsfälle nicht benötigt werden, wie z.B. JavaScript, können doch schon heute vom Anwendungsentwickler individuell deaktiviert werden.
Würden Sie stattdessen lieber mehrere Web-Engines parallel verwenden, eine umfangreiche und eine schlanke? Wie viele bräuchte es (zukünftig) dazwischen noch, um alle Anwendungszwecke abzudecken?