You're right - but the real win here is that hundred of thousands of developers already know HTML + CSS, and very few developers know XUL or even any native UI API. Given that these native APIs change with the platform, many developers have given up on them since HTML + CSS will be useful for the foreseeable future.
Is XUL really better than HTML + CSS? Probably. But HTML + CSS is getting a lot better (flexbox, etc), and tons of developers know it now and can contribute. Plus, dogfooding. I think it's a really good move!
Sure, RAM usage will probably get worse, but perhaps it will motivate them to improve that as well, and all users of the browser on all pages will benefit as a result.
I don't know if XUL is better than HTML + CSS, I haven't used XUL. I have used XAML and Qt, and the Android Layout Manager. and they are way easier to deal with.
In HTML, a button is not a button, it's a DIV with an CSS properties (which render differently depending on the browser) + some images + some Javascript. And that abstraction leaks a lot.
The equivalent in native code will be having to deal with Xlib in X11 or GDI on Windows every time you debug.
That said, there is value in HTML/CSS/JS UIs, I don't deny that, and I use them when appropriately. I still think native UIs are 'cleaner' to develop.
While that's true, a lot of the frustration with HTML/CSS/JS melts away when you have only a single target environment and don't have to worry about browser compatibility. Targeting a modern environment like Gecko would actually be quite nice; you could use a lot of modern ES6 features and Flexbox.
Is XUL really better than HTML + CSS? Probably. But HTML + CSS is getting a lot better (flexbox, etc), and tons of developers know it now and can contribute. Plus, dogfooding. I think it's a really good move!
Sure, RAM usage will probably get worse, but perhaps it will motivate them to improve that as well, and all users of the browser on all pages will benefit as a result.