My second thought was, for people who play a lot of ROMs, they're either doing it because they know more about those games than typical online metadata sources do; and/or a big chunk of them are modded or even completely homebrew.
But that's probably not what it means. Kids throw words around meaning all sorts of strange things these days.
And if it used a GUI at all, it implemented its own GUI directly using the API provided by the OS (or some library built on that; originally quite obnoxiously thin ones, but nowadays you can get some very nice abstractions). It didn't delegate HTML or CSS rendering to a web rendering engine, because those basically didn't even exist outside an actual dedicated web browser. Nor did it express the GUI layout in those terms at any point; it was expressed in terms of widgets again defined by whatever SDK, specifically for the purpose of creating GUIs - not hacks on top of the hypertext model.
You know, much like what had to be done to make the ROMs in the first place (although using SDKs oriented around receiving input from a controller, rather than a mouse and keyboard; and around displaying things like scrolling tile grids rather than movable windows).
(And it turns out it's still completely possible to make things this way, and I still do.)
The solution isn't ideal for those who hoard entire romsets, but it's great for those of us who curate their collections down to a more manageable size. That can be anywhere from a couple hundred to a couple thousand games, and the metadata sources are fairly robust at that scale.
It's a sort of complexity that seems, to me, completely beyond what the target audience - people who collect ROMs - would be interested in. After all, they're explicitly preserving software that itself works in a far more primitive way, because they have a personal interest in software that works in primitive ways.
Maybe this project is appealing to a totally different audience than most ROM managers