Auch bei SDK-Erweiterungen oder WebExtensions kann man zusätzliche Übersetzungen hinzufügen oder hardgecodete Strings ersetzen. JavaScript hat damit nichts zu tun, denn via JavaScript greifst du ja auch nur auf die vorhandenen Übersetzungen zu. Und JavaScript ist ja auch nicht mit neueren Architekturen neu dazu gekommen.
Dann sollten die Strings aber auch gut erreichbar sein. Und in XUL waren sie das. Auch wenn es meistens eine ganze Reihe von XUL-Dateien gab. Aber es ist mühselig, aus einer Datei wie der inject.js die Strings herauszusuchen. Du hast recht, wenn der Entwickler mir die Strings in Form einer jetzt messages.json zur Verfügung stellt. Dann brauche ich mich nicht mehr um JavaScript zu kümmern.
Meine Legacy-Erweiterung "FM Scene" (habe ich heute gemeinsam mit zwei anderen meiner Erweiterungen von AMO gelöscht) war auch eine XUL-Erweiterung und die hat sogar zwei verschiedene Sprachdateien pro Sprache gebraucht, eine für XUL, eine andere in einem anderen Format für JavaScript, also du siehst, das gab es damals schon, da kann ich eine eigene Erweiterung als Beispiel nennen.
Du siehst das unter dem Standpunkt eines Add-on-Entwicklers, der natürlich seine eigene Erweiterung kennt und das nötige Programmier-KnowHow hat. Du könntest mir natürlich entgegenhalten, dass du als Add-on-Entwickler nicht daran interessiert bist, dass jemand in deiner Erweiterung "herumpfuscht". Aber wenn die Lokalisierungsvoraussetzungen da sind, brauche ich das ja auch nicht tun.
Dass für die Übersetzung von HTML-Dateien bei WebExtensions derzeit keine fertige Lösung existiert, ist unglücklich, aber es ist nicht so, als wäre das nur bei XUL-Erweiterungen komfortabel gewesen. Im SDK war das auch ziemlich einfach. Es war auf jeden Fall eine schöne Übung für mich, mit XPath arbeite ich sonst nicht.
Wenn unsere Meinungen auch immer etwas auseinander gehen, hier aber muss ich sagen, dass du ein Herz für Übersetzer hast. Möglicherweise liegt es aber auch nur daran, um deine eigene Mutterprache neben Englisch unterzubringen. 
Ich widerspreche aber der Forderung, dass eine Lokalisierbarkeit erzwungen werden sollte. Vor allem ist das technisch gar nicht möglich, dass man das automatisiert, weswegen es notwendig wäre, dass Menschen die Architektur jeder Erweiterung verstehen und genauestens überprüfen, dass jeder Text, der sichtbar ist, in einer Sprachvariable ist und korrekt darauf zugegriffen wird.
Ich denke nicht, dass es in diesem Maße notwendig ist. Man prüft auf Vorhandensein des Ordners _locales mit dem Unterordner en-US und der notwendigen messages.json mit den englischen Strings. Man kann dann sicherlich davon ausgehen, dass der erforderliche JavaScript-Code in der entsprechenden .js-Datei eingebaut ist.
Darüber hinaus kann man das auch einfach nicht pauschal fordern. Es gibt nun einmal Add-ons, da hat es überhaupt keinen Sinn, sie mehrsprachig anzubieten. Nicht jedes Add-on hat ein internationales Publikum.
Unter XUL ging das auch. Da war in der überwiegenden Anzahl der Fälle der Ordner locale mit wenigstens dem Locale en-US vorhanden. Und wenn nicht, es war einfach mir die passenden XUL-Strings herauszufischen und meine eigene Locale-Ordnerstruktur anzulegen. Abgesehen davon, was nicht ist, kann ja noch werden. NTO hat derzeit neben Englisch nur 4 weitere Locales. Und es ist dir hoch anzurechnen, dass du nicht sagst, nun wegen den paar Locales, das lohnt sich doch nicht. Zumal noch zwei Locales zwei ganz kleine Sprachen betreffen, wo mancher großspurige Großsprachler schon wieder sagen würde: die sollen gefälligst Englisch lernen.
So nebenbei am Rande: Babelzilla soll sterben. Dort konnte man übersetzen, ohne sich Gedanken über Programmcode machen zu müssen. Aber nicht alle Entwickler haben ihre Erweiterungen dort eingestellt. Aber es waren doch ziemlich viel. Aber die Admin-/ Moderatoren-Kapazitäten waren dort auch dünn gesät.
und frohes Schaffen!