Yes, that is correctly understood and I don't have much more to add to it.
I agree that "it" can be ok for development, but not for production. At least in theory. If it is a truly good idea for OpenWrt I don't know.
Maybe my intentions were not clear because I am an innovator who is not afraid to make a leap.
There is no misunderstanding between the two (or three) of us. I fully understood the choices beforehand. In light of this, neither of you gave a straight answer to the precise answer. Why do you feel it mandatory to make the Web GUI/configuration interface of a router completely self contained in general? What if said GUI could have mobile apps for connecting to the router? What if the GUI was native JS compiled to a single HTML file, so the "installation by the user" would involve clicking "save as..."? I'm still waiting for your detailed arguments on the topic.
Although, I have yet to see a case when an industrial user will start configuring routers one by one on the field by their smart phones in their pocket. Or more precisely, using a non-smart phone or one which they do not own but rather they have just borrowed for the setup on a desert island.
I know a few professionals working in the field of industrial network design and deployment and they use netbooks because of the above reasons. Note that they have all kinds of funky tools preloaded. Do note that automated/bulk remote management of equipment is much more feasible than logging in and altering settings in each router one by one from a GUI anyway. So ideally you shouldn't be doing much besides equipment replacement on site, because power cycling can also be done remotely if you are classy. I hear you crying for basic status indication, however most devices have LEDs for this purpose and at a higher level, the only important status is whether the device can be managed remotely or not. If the cabling is in error or there exist complex interference, the technician will need to bring specialized equipment anyway. If the device shows signs of a hardware fault or a software bug, it will need to be replaced and inspected at HQ because it is usually difficult to debug or even just tell apart on site. The usual and cheapest procedure goes like if power cycling didn't help, replace components until the system starts working again, inspect or recycle the ruins later.
If I'd need to adjust settings on a desert island, I would have surely had all tools already loaded on my devices. Or even have a backup on the distributed storage of them locally, but that's besides the point.