I am not sure this is the right place, but I'd like to propose to bring the "luci-theme-openwrt" back as the default one.
First, it provides for a more compact UI over the new default "luci-theme-bootstrap" which spreads the information on a larger area.
Second, for normal output is uses the plain old black instead of those "shades of gray" for normal output. openwrt style uses the gays just for inactive text or disabled options. This is much easier to read, in my opinion.
I'm not familiar with the old UI but I would like to see JUCI moving over into LEDE similar to when FFLuCi became LuCI back in 2008
I'm not terribly loving current default LuCI theme either, but luci-theme-openwrt is plain ugly.
JUCI seems awesome, but storage and memory requirements are a bit scary for just a UI.
JUCI Flash and Memory Requirements (actual runtime usage):
~5M flash for full-featured frontend install (including http server)
~160k flash for backend rpc server (revorpcd)
16M ram (revorpcd + lighttpd server)I agree about the requirements, while I'd like to see the current ones.
And I could also agree about the ugliness of the openwrt theme.
But I am talking about effectiveness: reducing the amount of scrolling and hovering to do things.
Thus a more compact UI with a partial menu tree always visible is better than a fancy one than requires scrolling and hovering to display submenus.
But this is just my opinion and suggestion.
Better ones are welcome! 
The bootstrap theme works better on mobile devices. Maybe you can come up with a new theme that combines the responsiveness of bootstrap with the compact design of openwrt.
Hi Jow!
I could be wrong, but I don't see much to improve as far as responsiveness in openwrt theme.
It's made up by "just" a CSS file, a 152 bytes PNG (under /www/luci-static/openwrt.org) and a couple of HTML files (under /usr/lib/lua/luci/view/themes/openwrt.org).
In my opinion LuCI is rather slim and fast as it's now.
The improvements can be made in the theme effectiveness, more than to its speed.
Well it is far too wide on mobile screen for example.
I vote luci-theme-material as the new default!
The material theme bundles a full copy of jQuery and wastes a lot of space due to this.
I shall have a stab at a new, slim, responsive theme. After all, it's my dayjob to do these things, maybe I can give back this way. By the way, is the LEDE logo a placeholder, or is it "officially" sanctioned and supposed to stay like that?
For now the logo is official I guess but its not set in stone, maybe we should do a logo contest one day
Not to dump on anyone, but Tux in a box with LEDE written on it is neither the most creative nor the most distinctive logo. And horrible to reproduce in smaller sizes (like, for example, a 16x16 icon). But that's a sidequest of sorts, yeah.
Yeah, as I said its not set in stone and anyone professionally doing graphics can probably come up with something better in less time. I'm not tied to that logo, it just happend to be any identity we could use during the project inception phase.
Oh wow, there is a lot of hardcoded/pixel-based inline styling and outdated HTML markup in the LuCI pages. It's a bit of work to unravel that from a theme level. It can be done, for sure for the default pages, but I'm not sure how well that would play with luci-app-*
what would happen if someone removes that alltogether from LuCI and the luci-app-*?
I assume it would break current themes, but it might be worth it, if theming becomes much easier.
Yes it would break all current themes. Or to be more precise, the display of all luci-app pages that haven't been manually updated/stripped/refactored.
All current themes are pretty much just wrappers for what is hardcoded inside the HTML output. The containers look different, sometimes some elements (input boxes, buttons) look different. But pretty much all of the HTML inside is coded visually, not semantically, and there's only so much you can do by "poking from the outside".
I'm not really sure how one would go about this. Refactoring LuCI and/or a newer version with newer functions have been a topic for quite some time (see the already-somewhat-outdated approach with luci2, and the resource-heavy JUCI). I feel it would take some serious coordination and a consensus from the community. I have been in the position to refactor existing/outdated web projects before, and it's a thankless job, not least because pretty much every developer has his/her own spin on how to do things, even with a best practice put forward by HTML5/WAI/ARIA.
I think it would make most sense to finish LuCI2.
JUCI started as thin client side JavaScript only solution, then it forked rpcd, then it started to reintroduce Lua on the backend, then it switched from uhttpd to a patched lighttpd. Now its the bloat of Lua plus Lighttpd plus the frontend Javascript assets and neither lean nor lightweight anymore.
I'm not really opposed to it if people deem it useful. Then we should maybe fork it and make it work on uhttpd, rpcd and substitute the Lua backend code with C, like I attempted to do with LuCI2.
Edit: another thing I dislike about JUCI is the fact that it is GPLv3 vs. the Apache license using in LuCI
Possibly stupid question time! 
what's the status of LuCI2? How many man-hours would be needed to finish it?
metal said it is using a somewhat-outdated approach, what would be the modern approach?
Edit: another thing I dislike about JUCI is the fact that it is GPLv3 vs. the Apache license using in LuCI
Why?
(these questions always risk to start a copyleft vs permissive license flamewar, but I'm confident people here are adult enough to not do it)
In the beginning the JUCI project copied a lot of code from LuCI2 (or at least had very similar code) so I thought it would be a cool opportunity to use some of the improvements but that was made impossible due to the license change.
I also personally dislike the GPLv3 but the pro/contra arguments are all well known and have been discussed endless times so I won't restate them here.
luci2 was a good approach, but "lean and lightweight" it isn't either. It comes with jQuery, Bootstrap, "cbi.js" which I assume is some legacy script for input elements. All in all, the JavaScripts in luci2 weigh in at almost half a megabyte.
To compare: You can get AngularJS in about 160 kB and get a complete MVC(-ish, they call it MV-Whatever Works) framework.
Most of all, though, I don't get luci2. Instead of hardcoding everything in its own HTML/LUA snippet, everything is now hardcoded in its own JavaScript snippet. That's the same problem, just in a different candy wrapper.
Edit: To be clear, I really don't want to dump on anyone's efforts, least of all jow's.