Im Kontext des Freifunk-Selbstverständnisses als dezentral und community-besessen und -betrieben: durchaus, wenn nicht sogar zwingend. Ferner gibt es auf Server- und Netzebene durchaus Kooperationen als auch Informationsaustausch. Neben puppet-Rezepten aus dem Norden/Nordwesten gibt’s ansible-Speisekarten aus dem Münsterland … All das ist ein Angebot an lokale Macher; ein ‚kann‘, kein ‚muß‘.
Das sehe ich nicht, aus technischen (es gibt Entwicklungen neben Gluon) und aus organisatorischen Gründen. Sehe ich auch nicht als Ziel.
Die Entscheidung ist doch schon längst gefallen:
Es werden Mitmacher gesucht, keine Nutzer; die Nutzer können zu Mitmachern werden und darüber den lokalen Kurs mitgestalten — Nutzer sind willkommen, aber sicherlich nicht der Nabel der Welt. (Den Exkurs zu „Internet ist nur ein Dienst von vielen“ erspare ich uns mal.)
Second that. Natürlich »lebt« Freifunk auch von (Knoten-) Wachstum; aber eben nicht um jeden Preis. Ausgangspunkt war: meine Community hat für meinen Router keine Firmware, ergo gucke ich, ob nicht eine andere Community jene hat. Falls das Beispiel Schule macht, werden sich einige Communities überlegen, ob sie nicht neue Knoten erst händisch, meist dann auch erst nach Tagen, aufnehmen/freischalten wollen, wie es 2015 noch üblich war. Damit hätten dann wieder alle verloren 
Das ist Teil des Problems; sofern ihr Steckenpferd nicht die Technik im Hintergrund ist, könnte hier ein »Kollektiv« helfend einspringen. Klinkenputzen oder Pressetermine vor Ort wahrnehmen läßt sich weniger schlecht ortsungebunden realisieren.
20-40 Minuten; aber Gluon v2016 kannte kein Multidomain, damit wären es hier jene Zeit 3x pro Build. Und wenn Du dann der Hardwareschlacht (CPU-Power, Plattenplatz — für bis auf site.conf identische Firmware) aus dem Weg gehen willst und für zur Laufzeit austauschbare site.conf-Dateien sorgst … steht vor dem ersten Compilerlauf von v2017 folgende ersteinmal eine Anpassung. Klar, wenn man das auf git clone && make reduziert, ist eine neue Gluon-Version nach 1-2 Stunden (der erste Build dauert lange) durchgebaut …
Hmm. Babel ist jetzt vom Prinzip her nicht so anders als OLSR — es werden IP-Pakete geroutet, nicht Ethernetframes geswitched? Wie Babel dafür sorgen soll, daß 2001:bf7:170::12fe:edff:fecd:b9d0 über meinen Telekom-Anschluß erreichbar „ausgeleitet“ werden soll, erschließt sich mir auch nicht. Das ginge einzig mit NAT, z. B. NATPT, oder habe ich was verpaßt?