As annoying as browser-based GUI can be, I currently think it's the best solution outside of special cases like game engines that already have a distinct world and custom rendering pipeline that you'd like the GUI to integrate well with. Browsers are highly optimized for the purpose of displaying custom interactive UI, so it just makes sense to take advantage of that. And if you're using a browser based UI system, then it's reasonable to stick to an API paradigm that's more directly compatible with the WebIDL data model.
If you don't just reuse an existing system, you have to ask yourself how much of the existing system are you just going to reimplement, and is it really worth it? Sometimes it very much is! But generally it isn't.
I'm not free from sin; I very much enjoy reinventing the wheel from first principles. But I do it in order to learn, knowing that the intrinsic value to new systems is negative. It takes a miracle to get anyone to move from ab established system to a new untested one.
The answer is always yes. Rust is a Turing complete general purpose programming language, so you can do anything with it that you could do with any other programming language if you put enough effort in, with very few caveats. Although "with enough effort" is doing some very heavy lifting if all you know is that a language is Turing complete.
Rust has GTK bindings, and GTK is an OOP-y retained-mode GUI system that provides OOP-y functionality to Rust through the same system that it does for C. Rust isn't particularly well suited to OOP, thus the general trend of more Rust-first tools to pick different paradigms, but as much as OOP based GUI is well understood, OOP isn't a particularly great choice for GUI either; if you take a general survey of the "hot new thing" options in UI, while most do have OOP-y underpinnings, most also have a veneer which is distinctly not retained-mode OOP-y.
The Rust community has a strong inclination to pursue strongly "correct" designs, even if that means rejecting a body of existing practice... at least when rewriting in Rust. If you want something like an existing system, you'd be better off just using the existing system and its existing body of support. If you're building something new, it's much more worth it if you can do something better than the existing options.
In the abstract, no, or minimally so. It's very easy for simply implemented ECS solutions to have more wasted RAM, though (e.g. using dense component storage when utilization is sparse), and established OOP-y toolkits have generally picked up optimization over time to manage RAM bloat. At a minimum, GC runtimes have much smarter allocation tuning to use to optimize for common OOP GUI patterns than Rust can do with its general purpose allocator.
I haven't been following it, so I don't know how far along it actually is, but the first party bevy UI project is fully embracing ECS driven UI. But also bevy has been and I expect will remain somewhat stuck in the "feels like a research project" stage for a while yet, so while I have hopes for what it can eventually become, I'm not particularly inspired by the the short term.
Also, bevy UI is expected to be more focused on the "redraw everything every frame" usage, since games are redrawing everything anyway, but GUI for other purposes really would prefer to have reactive redraws that only does work when something changes.
After all, in the limit you can look at and use ECS as a weirdly shaped GC to just do the OOP patterns in. It's not the most optimal way to utilize ECS, but it works surprisingly well.
